[llvm-bugs] [Bug 42439] New: __int128 stack calling conventions are incorrect on x86-64

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=42439

            Bug ID: 42439
           Summary: __int128 stack calling conventions are incorrect on
                    x86-64
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: srhines at google.com
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, spatel+llvm at rotateright.com

This is a bug report that was posted internally at Google, since the user can't
register here on bugs.llvm.org:

Clang violates x86-64 calling convention in the obscure case when __int128 is
passed on stack.

Conside the following two functions:

__int128 foo(__int128 x, __int128 y, __int128 z, uint64_t a, __int128 c) {
   return x + y + z + a + c;
}

__int128 foo(__int128 x, __int128 y, __int128 z, uint64_t a, uint64_t b,
__int128 c) {
   return x + y + z + a + c;
}

Gcc generates identical code for these because __int128 have to be stored
aligned on stack (psABI says:

  Arguments of type __int128 offer the same operations as INTEGERs, yet they do
not fit into one general purpose register but require two registers.

For classification purposes __int128 is treated as if it were implemented as:
  typedef struct {
    long low, high;
  } __int128;
with the exception that arguments of type __int128 that are stored in memory
must be aligned on a 16-byte boundary.

Clang generates different code for these two functions:
  https://godbolt.org/z/ZKjb4Z

Note that both GCC and Clang show the alignment of __int128 properly as 16
bytes, but this is only getting ignored when the variable is passed on the
stack.

-- 
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/20190628/2016ca9e/attachment-0001.html>