From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@hurl.cygnus.com>
To: Chip Salzenberg <chip@perlsupport.com>
Cc: Joe Buck <jbuck@Synopsys.COM>, moshier@mediaone.net, tim@wagner.Princeton.EDU, tprince@cat.e-mail.com, bosch@gnat.com, burley@gnu.org, egcs@cygnus.com, hjstein@bfr.co.il
Subject: Re: /internet 
Date: Wed, 16 Dec 1998 16:20:00 -0000
Message-id: <28338.913853871@hurl.cygnus.com>
References: <19981216162248.Z22090@perlsupport.com>
X-SW-Source: 1998-12/msg00612.html

  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