This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFA] libstdc++/22203, aka PowerPC vs numeric_limits<integer>::traps
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