Re: problem building a GCJ-friendly GNU Crypto

[Geoff Keating <geoffk at geoffk dot org>]

> X-Original-To: geoffk@foam.wonderslug.com
> Date: Tue, 23 Sep 2003 11:38:24 -0400 (EDT)
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> Cc: roger@eyesopen.com, geoffk@geoffk.org, gcc-patches@gcc.gnu.org
> X-OriginalArrivalTime: 23 Sep 2003 15:43:02.0687 (UTC) FILETIME=[5F8BDAF0:01C381E9]
> 
> > I'm not surprised.  Many unspoken, non-portable assumptions are made
> > in GCC and I view them as bugs.  I don't think that the general
> > approach to that is  to add flags each time we find one.  The sooner,
> > it breaks, the better.
> 
> Personally, I believe that it is useful to have an option to provide
> left to right evaluation of expresssions where currently the C standard
> leaves the evaluation order undefined.  This is useful for numeric
> applications where evaluation order is sometimes critical.  As a result
> of fewer parentheses, it can make the code more readable.  Java seems to
> need this anyway, so it will get tested.

You're confusing the temporal order of evaluation with the grouping of
operations.  The C standard specifies the second completely, but the
first is restricted only by the sequence point rules.

For example,

result = a + b + c

is and always will be equivalent to 

result = (a + b) + c

but an implementation is allowed to make it

t1 = c
t2 = a + b
result = t2 + t1

or

t3 = a + b
t4 = c
result = t3 + t4

-- 
- Geoffrey Keating <geoffk@geoffk.org>