[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


            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

clang appears to use the wrong sequence for returning an object with head

For the attached testcase, clang -O2 generates the following code for function

    .globl    _Z3fooR1Y
    .align    16, 0x90
    .type    _Z3fooR1Y, at function
_Z3fooR1Y:                              # @_Z3fooR1Y
# BB#0:                                 # %entry
    movq    8(%rdi), %rax
    .size    _Z3fooR1Y, .Ltmp0-_Z3fooR1Y

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:


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