[llvm-bugs] [Bug 33112] New: ABI mismatch with GCC: missing/extra sret for variadic function templates

via llvm-bugs llvm-bugs at lists.llvm.org
Sat May 20 11:22:03 PDT 2017


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

            Bug ID: 33112
           Summary: ABI mismatch with GCC: missing/extra sret for variadic
                    function templates
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: syniurge at gmail.com
                CC: llvm-bugs at lists.llvm.org

Feed the following code to https://godbolt.org/:

#include <tuple>

using namespace std;

template<typename... _Elements>
    tuple<_Elements...>
    forward_as_tuple2(_Elements... __args) noexcept
    { return tuple<_Elements...>(__args...); }

void f() {
    forward_as_tuple2("s");
}

Below is the amd64 disassembly for GCC 5.4 vs Clang 3.9. The function produced
by GCC expects two argument registers, one of them holding the sret pointer.

When I mixed libraries built by GCC and by Clang this resulted in hard to track
bugs. I don't have the will to investigate further (is it truly related to
variadic function templates I don't know), but wanted to let you know.


GCC
Dump of assembler code for function
std::forward_as_tuple<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >&&):
=> 0x0000000000c90dac <+0>: push %rbp
0x0000000000c90dad <+1>: mov %rsp,%rbp
0x0000000000c90db0 <+4>: sub $0x10,%rsp
0x0000000000c90db4 <+8>: mov %rdi,-0x8(%rbp)
0x0000000000c90db8 <+12>: mov %rsi,-0x10(%rbp)
0x0000000000c90dbc <+16>: mov -0x10(%rbp),%rax
0x0000000000c90dc0 <+20>: mov %rax,%rdi
0x0000000000c90dc3 <+23>: callq 0x636fb0
<std::forward<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >(std::remove_reference<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::type&)>
0x0000000000c90dc8 <+28>: mov %rax,%rdx
0x0000000000c90dcb <+31>: mov -0x8(%rbp),%rax
0x0000000000c90dcf <+35>: mov %rdx,%rsi
0x0000000000c90dd2 <+38>: mov %rax,%rdi
0x0000000000c90dd5 <+41>: callq 0xc90ce2
<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&&>::tuple<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
void>(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&&)>
0x0000000000c90dda <+46>: mov -0x8(%rbp),%rax
0x0000000000c90dde <+50>: leaveq 
0x0000000000c90ddf <+51>: retq 
End of assembler dump.

Clang
Dump of assembler code for function
std::forward_as_tuple<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >&&):
=> 0x000000000097ba50 <+0>: push %rbp
0x000000000097ba51 <+1>: mov %rsp,%rbp
0x000000000097ba54 <+4>: sub $0x10,%rsp
0x000000000097ba58 <+8>: mov %rdi,-0x10(%rbp)
0x000000000097ba5c <+12>: mov -0x10(%rbp),%rdi
0x000000000097ba60 <+16>: callq 0x644c20
<std::forward<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >(std::remove_reference<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > >::type&)>
0x000000000097ba65 <+21>: lea -0x8(%rbp),%rdi
0x000000000097ba69 <+25>: mov %rax,%rsi
0x000000000097ba6c <+28>: callq 0x97c180
<std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&&>::tuple<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >,
void>(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >&&)>
0x000000000097ba71 <+33>: mov -0x8(%rbp),%rax
0x000000000097ba75 <+37>: add $0x10,%rsp
0x000000000097ba79 <+41>: pop %rbp
0x000000000097ba7a <+42>: retq 
End of assembler dump.

-- 
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/20170520/abc75ec3/attachment.html>


More information about the llvm-bugs mailing list