[cfe-dev] [libc++] numeric.limits.members/traps.pass.cpp and arm

[JF Bastien]

AFAIK it could be the dynamic linker detecting that the HW supports integer
division, or the runtime library could be unconditionally called (so,
determined at compile time). I'd say in all cases it's "before the program
starts", for some definition of "starting".


On Wed, Nov 27, 2013 at 1:45 PM, Nico Weber <thakis at chromium.org> wrote:

> I think the standard says something like "traps should be true if programs
> would trap at program start, before setting any custom options". How do you
> pick a runtime library? Is that done through a compiler flag?
>
>
> On Wed, Nov 27, 2013 at 6:35 AM, JF Bastien <jfb at google.com> wrote:
>
>> (A bit of a late comment, apologies.)
>>
>>> >
>>> test/language.support/support.limits/limits/numeric.limits.members/traps.pass.cpp
>>> checks that std::numeric_limits<char>::traps is true, but include/limits
>>> only sets it to true on intel as far as I can tell:
>>> >
>>> > #if __i386__ || __x86_64__
>>> >     static _LIBCPP_CONSTEXPR const bool traps = true;
>>> > #else
>>> >     static _LIBCPP_CONSTEXPR const bool traps = false;
>>> > #endif
>>> >
>>> > How is this test supposed to work on arm? Should the test check for
>>> __i386__ || __x86_64__ too?
>>> >
>>> > Thanks,
>>> > Nico
>>>
>>> I don't believe this test would pass on arm as currently configured.  I
>>> do not know what std::numeric_limits<char>::traps should be on arm.  But it
>>> would be a good thing to find out, fix it if libc++ currently gets the
>>> wrong answer, and make
>>> test/language.support/support.limits/limits/numeric.limits.members/traps.pass.cpp
>>> consistent with whatever was done in include/limits.
>>>
>>
>> I had a similar issue with PNaCl where we guarantee that integer division
>> by zero traps. IIUC some runtime libraries always trap on divide by zero,
>> and we modified the ARM code generation to also trap if udiv/sdiv is
>> available. It seems like just adding ARM to the mix may not be the right
>> solution either, but I'm not sure what is since the answer may depend on
>> the runtime library.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131127/d892e1f2/attachment.html>