On Tue, Oct 2, 2012 at 4:21 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
> On Tue, 2 Oct 2012, Gabriel Dos Reis wrote:
>
>> On Tue, Oct 2, 2012 at 3:57 AM, Marc Glisse <marc.gli...@inria.fr> wrote:
>>>
>>> (Forgot libstdc++...)
>>>
>>>
>>> Hello,
>>>
>>> here is the patch from PR54686. Several notes:
>>>
>>> * I'll have to ask experts if std::abs(unsigned) (yes, a weird thing to
>>> do,
>>> but still) is meant to return a double...
>>
>>
>> don't we have a core issue about preferring unsigned -> long or long long?
>
>
> Here I am talking of a library issue: the wording that says that there are
> sufficient overloads such that integer types call the double version of math
> functions. It is fairly obvious that it doesn't apply to abs(long) for
> instance which has an explicit overload. For short or unsigned, I still read
> it as saying that it converts to double...
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.
>
>
>>> * I still don't like the configure-time _GLIBCXX_USE_INT128, I think it
>>> should use defined(__SIZEOF_INT128__), which would help other compilers.
>>
>>
>> Why would that be a problem with the appropriate #define?
>
>
> 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.
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.
>
>
>>> * newlib has llabs, according to the doc. It would be good to know what
>>> newlib is missing for libstdc++ to detect it as C99-ready.
>>>
>>> I tested a previous version (without __STRICT_ANSI__) on x86_64-linux-gnu
>>> and Oleg Endo did a basic check on sh/newlib. I'll do a last check after
>>> the
>>> review (no point if the patch needs changing again).
>>
>>
>> In general, I think I have a bias toward using compiler intrinsics,
>> for which the
>> compiler already has lot of knowledge about.
>
>
> 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.
-- Gaby
