[LLVMbugs] [Bug 19675] New: [x86-64 Itanium ABI] clang uses wrong return location for class with head padding
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Wed May 7 07:50:49 PDT 2014
http://llvm.org/bugs/show_bug.cgi?id=19675
Bug ID: 19675
Summary: [x86-64 Itanium ABI] clang uses wrong return location
for class with head padding
Product: clang
Version: 3.4
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: greened at obbligato.org
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12488
--> http://llvm.org/bugs/attachment.cgi?id=12488&action=edit
Testcase
clang appears to use the wrong sequence for returning an object with head
padding.
For the attached testcase, clang -O2 generates the following code for function
foo:
.globl _Z3fooR1Y
.align 16, 0x90
.type _Z3fooR1Y, at function
_Z3fooR1Y: # @_Z3fooR1Y
.cfi_startproc
# BB#0: # %entry
movq 8(%rdi), %rax
ret
.Ltmp0:
.size _Z3fooR1Y, .Ltmp0-_Z3fooR1Y
.cfi_endproc
The class Y should be classified INTEGER under the x86-64 ABI. It has eight
bytes of head padding because it inherits from an empty base class and has a
member that also inherits from the same empty base class. By my reading of the
ABI, foo should return the Y object in (RAX, RDX), with RDX containing the
meaningful bits (the long value).
The Intel compiler generates the code I would expect for this testcase.
gcc produces code similar to clang and I have also filed a bug there:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61082
There at least seems to be some disagreement as to the interpretation of the
x86-64 and/or Itanium ABIs. I would like to get some clarity on this because
it's an interoperability issue. Can someone point to wording in one or both of
the ABI documents that specifies clang's behavior here? I have looked for a
good long while and haven't come up with anything.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140507/18f6fb0a/attachment.html>
More information about the llvm-bugs
mailing list