llvm dev - Sep 2008 - [LLVMdev] Possible bug in x86 code generation for fastcall on gnu/linux

Hi,

When compiling this function:

__attribute__((fastcall)) int f(int x, int y) {
    return 0;
}

llvm 2.3 produces the following x86 assembler (with directives removed):

f:
	xorl	%eax, %eax
	ret	$4

Where as GCC (version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) produces:

f:
	xorl	%eax, %eax
	ret

Note the difference in ret.

Functions calling a fastcall function in llvm adjust the stack by 4 to
compensate for the above in llvm generated code,
whereas GCC generated function do not, since they do they need to.

Mark.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2762 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080930/0745924c/attachment.bin>

Hi, I don't see this with llvm from svn, so
it looks like it has been fixed.

Ciao,

Duncan.

PS: Tested at -O1 and -O3, with and without a frame pointer.

Duncan,
Just checked out the latest version.
It works as expected.

Thanks,
Mark.

-----Original Message-----
From: Duncan Sands [mailto:baldrick at free.fr]
Sent: Tue 30/09/2008 12:45
To: llvmdev at cs.uiuc.edu
Cc: Mark Shannon
Subject: Re: [LLVMdev] Possible bug in x86 code generation for fastcall on
gnu/linux
 
Hi, I don't see this with llvm from svn, so
it looks like it has been fixed.

Ciao,

Duncan.

PS: Tested at -O1 and -O3, with and without a frame pointer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080930/da36a37d/attachment.html>