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


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

RE: Reassociation


         Date: 12/17/98
         From: Tim Prince                                   PRINCTC3 - SOLARDEC
      Subject: RE: Reassociation

Date:  12/17/1998  08:12 am  (Thursday)
From:  Tim Prince
To:  MRG41."RALPH:MRS:SN_L=IBMMAIL:SN_U=N4244063",
     A1.MRS_RALPH.SN_U=INTERNET|SN_L=IBMMAIL
Subject:  RE: Reassociation


While I have only the summary articles of the IEEE P754 and
P854 standards, I am convinced that these standards deal only
with single operations, not with groupings where reassociation
is possible.  Except that the reason for choosing exponents
which increase by 3 bits with each increase in format width is to
assure that the wider format will protect against intermediate
over/under-flow when 3 operands (of the next smaller format) are
multiplied together.  If the multiplication of 4 operands produces
over or under-flow in spite of the width increase, it will happen
regardless of reassociation.  Clearly, this was done to relieve the
programmer of concerns about intermediate over/under-flow.

Fortran compilers always have been expected to perform
reassociations such as Jeff mentioned, with parentheses and
assignments being treated as barriers to reassociation.  As I
pointed out yesterday, there are reputable compilers which go
beyond that, but I side with those who say that shouldn't happen
without a specific additional option selection.

I am no C expert, but my copy of draft C9X standard touches on
this:

"Except as indicated by the syntax [operator precedence,
parentheses] or [when function call, && || ?: , operators
intervene], the order of evaluation of subexpressions and the
order in which side effects take place are both unspecified".

So I understand the C9X rules on this to be consistent with what
we have been accustomed to in Fortran, and I would go so far as
to suggest that C9X be taken as a guide.  Certainly that draft
standard shows evidence of incorporation of some expert
experience.

In view of the fact that left-to-right evaluation has been expected
from C compilers and that most current Fortran compilers follow
that scheme, I have tended to take that into account when setting
up expressions where the compiler may apply Common
Sub-expression Evaluation.  I don't see that as anything more
than a mild suggestion as to how the compiler should treat my
code.

From: Joe Buck <jbuck@Synopsys.COM>
> I believe the example you were talking about yesterday violates
IEEE,
> since the reordering you suggested can change the value of
the result
> (by causing an intermediate (c*d) to overflow, when left to right
> evaluation would not cause an overflow):

Does IEEE require left-to-right evaluation of y = a * b * c * d;
when there are no parentheses present?

Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org

           To:                                              INTERNET - IBMMAIL
                                                            N4244063 - IBMMAIL


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