From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@hurl.cygnus.com>
To: Joe Buck <jbuck@Synopsys.COM>
Cc: 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:37:00 -0000
Message-id: <28398.913854887@hurl.cygnus.com>
References: <199812161958.LAA29146@atrus.synopsys.com>
X-SW-Source: 1998-12/msg00614.html

  In message < 199812161958.LAA29146@atrus.synopsys.com >you write:
  > > > Does IEEE require left-to-right evaluation of y = a * b * c * d;
  > > > when there are no parentheses present?
  > > 
  > > I think that IEEE does not actually say anything about it.  C9X, however,
  > > does contain some remarks such as the following, which might have come
  > > from NCEG.
  > 
  > >                int a, b;
  > >                /* ... */
  > >                a = a + 32760 + b + 5;
  > > 
  > >        the expression statement behaves exactly the same as
  > > 
  > >                a = (((a + 32760) + b) + 5);
  > >
  > >        due to the associativity and precedence of these  operators.
  > >        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.
  > 
  > If this is the rule, then a*b*c*d can't be rearranged in C9X.  However,
  > it appears that it can be rearranged in Fortran (where the user must
  > use parentheses to force the order of evaluation) as well as in the
  > current ANSI/ISO C.
Someone is starting to mix integer vs FP.

For integer the reassociation rules are much simpler.  Our current target
set does not trap on overflow and overflows wrap in the expected manner.

For such targets aggressive integer reassociation is a valid transformation
(as long as the language does not mandate overflow checking at this level).

The rules for FP are different becuase it's not 100% certain that the
results after reassociation will be the same as before reassociation.  Though
I believe in the case reassociating a series of multiplies we are safe.

Again, I have no intention of reassociating a + 5 + b + c for FP because of
overflow concerns.  The same restrictions are not necessary for multiplies
though as far as I can tell.

I challenge anyone to come up with a case where a reassociation of
a * b * c * d  produces different results than ((a * b) * c) * d.


jeff