[Bug target/77597] New: GCC 6.2 / LLVM 3.9 name mangling discrepancy for function with instantiated template in signature whose template argument involves an ABI tag.

[greenc at fnal dot gov]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77597

            Bug ID: 77597
           Summary: GCC 6.2 / LLVM 3.9 name mangling discrepancy for
                    function with instantiated template in signature whose
                    template argument involves an ABI tag.
           Product: gcc
           Version: 6.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: greenc at fnal dot gov
  Target Milestone: ---

Created attachment 39624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39624&action=edit
Code and build script to demonstrate mangling discrepancy

The attached tar file implements a code example declaring and defining the
function:

void gallery::throwHandleWhyFailed(std::shared_ptr<art::Exception const>
whyFailed);

which, when all's said and done, expands to (according to a capable c++filt):

gallery::throwHandleWhyFailed(std::shared_ptr<cet::coded_exception<art::errors::ErrorCodes,
&art::ExceptionDetail::translate[abi:cxx11]> const>)

Despite both compilers claiming to follow the Itanium ABI and mangling standard
for x64_64 architectures, g++ 6.2 and clang++ 3.9 apparently disagree on the
mangled function name.

By using the included Dockerfile or obtaining fnalart/llvm:3.9 from dockerhub,
one obtains an Ubuntu 16.04 with the addition of G++-6.2 and LLVM 3.9.0. Then,
one can do (e.g.):

$ docker run --rm -v `pwd`:/work -w /work fnalart/llvm:3.9 ./build.sh g++-6
_ZN7gallery20throwHandleWhyFailedESt10shared_ptrIKN3cet15coded_exceptionIN3art6errors10ErrorCodesEXadL_ZNS3_15ExceptionDetail9translateB5cxx11ES5_EEEEE
gallery::throwHandleWhyFailed(std::shared_ptr<cet::coded_exception<art::errors::ErrorCodes,
&art::ExceptionDetail::translate[abi:cxx11]> const>)

and

$ docker run --rm -v `pwd`:/work -w /work fnalart/llvm:3.9 ./build.sh
clang++-3.9
_ZN7gallery20throwHandleWhyFailedESt10shared_ptrIKN3cet15coded_exceptionIN3art6errors10ErrorCodesEXadL_ZNS3_15ExceptionDetail9translateB5cxx11ENS6_6errors10ErrorCodesEEEEEE
gallery::throwHandleWhyFailed(std::shared_ptr<cet::coded_exception<art::errors::ErrorCodes,
&art::ExceptionDetail::translate[abi:cxx11]> const>)

Note that c++filt demangles the symbol in each case to the same C++ function
signature.

It is unclear to me as a non expert whether GCC or LLVM is at fault, or whether
the standard is sufficiently unclear that either mangled name is valid (which
would be bad). I'm currently waiting for permission to obtain an LLVM Bugzilla
account in order to submit this issue to them also. When I have successfully
submited same, I will provide a link to it here.