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

Hi Howard,

test/language.support/support.limits/limits/numeric.limits.members/traps.pass.cpp checks that std::numeric_limits::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.

Howard

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

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?

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