abs(long long)

[Marc Glisse]

On Tue, 2 Oct 2012, Gabriel Dos Reis wrote:

> I understand that it is originally a library issue, but I don't think
> it makes sense to resolve it in isolation of that core issue.

They seem mostly orthogonal to me, since the library only uses an informal 
language describing the desired outcome and not the actual overloads 
necessary to achieve it, whereas the core issue is about determining 
priorities for a non-ambiguous overload resolution (if we are talking 
about the same, where Jens Maurer has a proposal).

>> 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.

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.

>> 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. 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