va_arg broken with x86_fp80

[efriedma-quic]

Bugzilla Link	2379
Resolution	FIXED
Resolved on	Jan 04, 2013 12:20
Version	unspecified
OS	Linux

Extended Description

Testcase:

; ModuleID = '-'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i686-pc-linux-gnu"

define i32 @​a(i32 %i, ...) {
entry:
%l = alloca i8*
%l1 = bitcast i8** %l to i8*
call void @​llvm.va_start( i8* %l1 )
%xxx = va_arg i8** %l, x86_fp80
%ret = va_arg i8** %l, i32
call void @​llvm.va_end( i8* %l1 )
ret i32 %ret
}

declare void @​llvm.va_start(i8*) nounwind
declare void @​llvm.va_end(i8*) nounwind

define i32 @​main() {
entry:
%call = call i32 (i32, ...)* @​a( i32 1, x86_fp80 1.0, i32 195948557 )
%cmp = icmp ne i32 %call, 195948557
br i1 %cmp, label %ifthen, label %ifend

ifthen: ; preds = %entry
call void @​abort( )
br label %ifend

ifend: ; preds = %ifthen, %entry
ret i32 0
}

declare void @​abort()

Run through "llvm-as | lli", should not call abort(), but it does call abort() on x86 linux. And if you replace the references to x86_fp80 with references to double, it does in fact work.

It appears that the implementation of va_arg is ignoring the alignment of x86_fp80.

[llvmbot]

It does. Darwin expands va_arg in the FE, so llvm-gcc does not have this problem there. I am not sure what Linux does but that may be the expectation there too.

[efriedma-quic]

llvm-gcc always expands va_arg in the front-end; is that supposed to mean it's okay for the va_arg instruction to be broken?

[llvmbot]

The testcase passes in llvm revision 171467.