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

Nico Weber thakis at chromium.org
Wed Nov 27 13:45:43 PST 2013


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/20131128/78578d66/attachment.html>


More information about the cfe-dev mailing list