LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 1740 - x86-64 va_arg instruction is not implemented correctly.
Summary: x86-64 va_arg instruction is not implemented correctly.
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: X86 (show other bugs)
Version: 1.0
Hardware: PC Linux
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
: 3569 (view as bug list)
Depends on:
Blocks: 6796 2825
  Show dependency tree
 
Reported: 2007-10-23 22:36 PDT by Tomas Lindquist Olsen
Modified: 2013-01-04 11:31 PST (History)
9 users (show)

See Also:
Fixed By Commit(s):


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Lindquist Olsen 2007-10-23 22:36:22 PDT
Using the LLVM 2.1 release, the following test case segfaults when run;

a.ll:

define i32 @test(i32 %X, ...) {
  %ap = alloca i8*, i32 1024
  %ap2 = bitcast i8** %ap to i8*
  call void @llvm.va_start(i8* %ap2)
  %tmp = va_arg i8** %ap, i32
  call void @llvm.va_end(i8* %ap2)
  ret i32 %tmp
}

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

define i32 @main(i32, i8**, i8**) {
  %ret = call i32(i32, ...)* @test(i32 0, i32 0)
  ret i32 %ret
}

result:

$ llvm-as -f a.ll && llc -f a.bc && gcc a.s && ./a.out
Segmentation fault
$
Comment 1 Chris Lattner 2008-02-18 01:15:33 PST
Verified on darwin/x86-64
Comment 2 Dan Gohman 2008-05-12 13:43:40 PDT
There is currently no implementation of the x86-64 va_arg operation.
va_arg on x86-64 was going through the default legalize Expand logic,
generating code that was incorrect for x86-64. This has temporarily
been changed to a compiler abort, to avoid silently generating invalid
code.

llvm-gcc isn't affected because it doesn't currently use LLVM's va_arg
instruction on x86-64; it does the lowering before translating to LLVM.


Comment 3 Chris Lattner 2008-10-16 02:11:26 PDT
*** Bug 2825 has been marked as a duplicate of this bug. ***
Comment 4 Duncan Sands 2008-11-03 15:05:25 PST
There is a similar problem when using i8 or i16 on x86-32:
these are passed in 4 byte wide stack slots (for the usual
calling convention at least), but the generic expansion
code increments the pointer by 1 (resp. 2) rather than 4.
Comment 5 Chris Lattner 2009-02-13 00:37:07 PST
*** Bug 3569 has been marked as a duplicate of this bug. ***
Comment 6 Thomas B. Jablin 2013-01-04 11:31:08 PST
Works for me in llvm 3.3 (trunk 170352).