[cfe-dev] solaris-specific mangling for g++ compat

[Fedor Sergeev via cfe-dev]

On Fri, Jul 14, 2017 at 12:10:08AM +0300, Fedor Sergeev via cfe-dev wrote:
> On Thu, Jul 13, 2017 at 01:34:24PM -0400, James Y Knight wrote:
> > So, uh, why did solaris's stdlib.h header move these four types in the first
> > place? It sounds like there was some code in the system header that
> > conditionally put them into either the global namespace, or into the std
> > namespace, dependent on the value of __cplusplus, yet all C++ compilers ever
> > used on solaris were setting __cplusplus to the version where they were in the
> > global namespace.
> > So...I'm rather confused, then, as to why this mangling change was made in gcc
> > in the first place, instead of just modifying the system header to not do
> > that. Surely it'd have been saner to move the definitions back to the global
> > namespace unconditionally? (And, I think that could even still be done?)
> 
> I really have no idea on what the full story was.
> Probably Rainer can shed some light as he was quite involved in that discussion
> (see https://gcc.gnu.org/ml/gcc-patches/2011-08/msg00834.html)

Well, Rainer seems to be on vacation...

> 
> I was rather surprised to learn about this strange solution
> when I hit it with Oracle Studio compiler couple years ago.
> 
> > For comparison, on linux glibc, tm, div_t, ldiv_t, and lconv are all just
> > defined in :: and imported into std:: with using...
> 
> I'm going to ask around in Solaris, but if we ever manage to fix it in future Solaris versions,
> headers on older ones will still trigger this incompatibility. :(

Fixing this issue in the headers appears to be more problematic than it seems.
Solaris headers have to support both GCC and Studio C++ compilers, and as you might imagine
fixing for g++ (bringing, say, struct tm from std into global) will break Studio C++
mangling pretty much in the same manner.

And adding conditional guards that differentiate between ABIs into the headers would
just move the mess from compilers into the headers.

So given the status quo, I dont see a way for a clean solution when adding one more compiler
to the equation (Clang).

For now as my task is to get a functional Clang/LLVM on Solaris I would rather go with adding
a gcc'ish change to Clang's ItaniumMangle.cpp and then try to sort out that mess in Solaris headers
so at some time later it would be possible to phase this hack out.

regards,
  Fedor.

> 
> regards,
>   Fedor.
> 
> > 
> > 
> > On Thu, Jul 13, 2017 at 12:56 PM, Fedor Sergeev via cfe-dev <
> > cfe-dev at lists.llvm.org> wrote:
> > 
> >     Greetings folks,
> > 
> >     I just filed a bug on clang mangling:
> >       https://bugs.llvm.org/show_bug.cgi?id=33767
> > 
> >     which is not clang's bug per se, but rather a bug-incompatibility
> >     with gcc on Solaris (more details in bug report).
> > 
> >     gcc deliberately chose to diverge from mangling as specified by C++ ABI
> >     in order to keep binary compatibility
> >     (see https://gcc.gnu.org/ml/gcc-patches/2011-08/msg00834.html
> >      for discussion of that patch).
> > 
> >     When clang on Solaris links with libstdc++ this binary compatibility
> >     issue kicks in.
> > 
> >     I wonder would the patch doing Solaris-only hack to the mangling
> >     to maintain gcc binary compatibility be welcome here?
> >     Unconditionally or under some flag?
> > 
> >     regards,
> >       Fedor.
> >     _______________________________________________
> >     cfe-dev mailing list
> >     cfe-dev at lists.llvm.org
> >     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > 
> > 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev