On Tue, Oct 2, 2012 at 8:07 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
>>> The library installed by the system was compiled with g++, and is then
>>> used
>>> with clang++. If we can avoid installing 2 config.h files to make that
>>> work...
>>
>>
>> Two things:
>> 1. that is clearly a clang problem. I don't think it is libstdc++'s job
>> tp try to solve clang's misguided configuration and installation.
>
>
> Translated: libstdc++ should only ever be used with the very version of g++
> that was used to compile it. clang++, icpc, sunCC, etc should never try to
> use a libstdc++ compiled with another compiler.
Obviously, I cannot require you to exercise common sense
and keep in check non-sensical strech.
libstdc++ was and is developed for GCc/g++. If you are have
a 3rd party compiler that you would like to use with g++/libstdc++, you
should
(a) either convince your 3rd party compiler supplier
to understand the library you already have (libstdc++), or
(b) supply yourself the glue between libstdc++ and your compiler.
Many compilers have done that in the past; I don't see anything
special with clang++
Whining on this list about libstdc++ internal macros and your dislike
of them is not going to produce anything today or tomorrow.
>
> I am not saying libstdc++ should go to great lengths to support other
> compilers, but when it is actually easier to support them than not to...
> (testing a macro is easier than a configure test)
>
>
>> 2. I am not sure you understand what I wrote: you can leave the
>> use of the current macro the way it is if you appropriately
>> define it in terms of what you want to change it to.
>
>
> I was complaining about the configure-time nature of the macro. If it is
> defined at each compiler run based on __SIZEOF_INT128__, I am happy.
I am saying to can arrange to supply the appropriate definition
without having to change the uses.
>
>>> More precisely, does that mean you want __builtin_llabs instead of
>>> ::llabs?
>>> I thought the compiler knew they were the same.
>>
>>
>> Yes. Another reason is that it simplifies the implementation AND if
>> people want want to do something with the intrinsics' fallback
>> libstdc++ will gracefully deliver that.
>
>
> I don't see how that simplifies the implementation, it is several characters
> longer than ::llabs, and we still need to handle llabs.
You are on the wrong track if you are taking the number of characters
used in the implemetation.
> Or do you mean:
> always call __builtin_llabs (whether we have an llabs or not), and let the
> compiler replace it with either (x<0)?-x:x or a library call (I assume it
> never does that unless it has seen a corresponding declaration)?
>
> Note that I am happy to let you take over this PR if you like.
>
> --
> Marc Glisse
