Re: [RFA] libstdc++/22203, aka PowerPC vs numeric_limits<integer>::traps

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Benjamin Kosnik <bkoz@redhat.com> writes:

| > I believe the objects might want to be declared volatile, to side-step
| > excessive cleverness from the compiler.  For the integer types, we
| > only need to test for
| > 
| >    int
| >    unsigned
| >    long
| >    unsigned long
| >    long long                    -- guarded by extension
| >    unsigned long long           -- guarded by extension
| 
| Great.
| 
| FYI there is no guard on <limits> for long long and ull, so I don't see
| a need to guard in this specific test. (This is unlike io, for instance.)

That is fine then -- I don't remember the exact official policy with
respected to long long.  My recollection was that it is still an
extension. 

| 
| > For floating points, trpping is a different, more complicated story.
| > If is_iecxxx is true, then division by zero would not trap (infinity).
| > If is_iecxxx is false, we don' know (VAX may trap for 0/0 -- I have to
| > check).
| > For most cases (i.e. IEE-754), trapping for floating points have to do
| > with whether there is a support for signaling NaN.
| 
| I'm going to punt on the fp types for now, if you feel ambitious in the
| future, feel free to do something complicated.

the point I was trying to make is that the division by zero for
floating point is probably not testing anything :-)

-- Gaby