This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: /internet
- To: Chip Salzenberg <chip at perlsupport dot com>
- Subject: Re: /internet
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Wed, 16 Dec 1998 17:17:51 -0700
- cc: Joe Buck <jbuck at Synopsys dot COM>, moshier at mediaone dot net, tim at wagner dot Princeton dot EDU, tprince at cat dot e-mail dot com, bosch at gnat dot com, burley at gnu dot org, egcs at cygnus dot com, hjstein at bfr dot co dot il
- Reply-To: law at cygnus dot com
In message <19981216162248.Z22090@perlsupport.com>you write:
> According to Joe Buck:
> > NCEG:
> > > Thus, the result of the sum (a + 32760) is next added to b,
> > > and that result is then added to 5 which results in the
> > > value assigned to a. On a machine in which overflows
> > > produce an explicit trap and in which the range of values
> > > representable by an int is [-32768, +32767], the
> > > implementation cannot rewrite this expression as
> > >
> > > a = ((a + b) + 32765);
> >
> > Amazing. These guys are trying to turn C into Ada.
>
> Hey, it only applies to machines where integer overflows trap. Would
> it be a problem to say that EGCS targets should never include such
> environments? Integer overflow traps are almost unheard of in C.
We'd have to introduce some new code to handle such an architecture if
one was to ever come along.
Right now GCC assumes integer instructions do not trap on overflow and wrap
in the expected manner. As long as gcc is presented with that kind of
architecture it can reassociate integer operations in useful ways.
Some of gcc's existing targets have instructions which trap on overflow, but
they also include corresponding instructions which do not trap. GCC uses
the non trapping variants.
jeff