This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Benjamin Kosnik <bkoz@redhat.com> writes:

| > Well, it would certainly be nice to test this, but please note there
| > are no signal or traps testing for numeric_limits presently.
| 
| Find test attached, thanks Paolo/Ulrich W. (Let's see what else breaks!)
| 
| If this is done, we should split out the existing numeric_limits tests as well.

Great minds think alike :-)

I just sent something basically similar.

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


bool, char (and variants), short (and variants) are promoted to int
before arithmetic operations.


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.


-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]