problem building a GCJ-friendly GNU Crypto
Roger Sayle
roger@eyesopen.com
Sun Sep 21 01:22:00 GMT 2003
On 20 Sep 2003, Gabriel Dos Reis wrote:
> Geoff Keating <geoffk@geoffk.org> writes:
> | Roger Sayle <roger@eyesopen.com> writes:
> |
> | > I'm currently working on a patch to add an -fevaluation-order command
> | > line option to GCC, that sets a flag_evaluation_order variable that
> | > can be checked during constant folding to preserve left-to-right
> | > evaluation order of binary expressions. This can then be enabled by
> | > default by the java front-end, which should help make libbackend.a
> | > more java friendly.
> |
> | Although I agree that it'd be better if the constant folder didn't do
> | things that break Java, I don't see why we need an extra command-line
> | flag for this. GCC already has way too many command-line flags, and
> | this one seems to add particularly little value.
>> seconded. The backend should just know that it is evaluating bits
> from Java. No?
I'm cool with just adding flag_evaluation_order without a corresponding
command line option. Indeed my motivation for Cc'ing gcc-patches was
to get an impression of whether an option was useful/needed.
A new option would allow easy testing of correct semantics from the other
front-ends, and -fno-evaluation-order could be used to preserve current
gcj semantics, and it does follow the current convention with -ftrapv,
-fwrapv, -frounding-math, -fsignaling-nans, etc... but I do agree that
we already have far too many command line options, and our documentation
is particularly poor at distinguishing options intended for users from
those intended for GCC developers (dump flags, param settings, etc...).
I'll just add the global variable.
Many thanks.
Roger
--
More information about the Java
mailing list