Re: PR 1159/1412

[Tom Tromey <tromey at redhat dot com>]

>> Constant folding.  However, we can't do this on bytecode until we
>> have a version of fold() that obeys Java semantics.

Per> I missed the specifics of this problem.  Could you summarize?

The easiest way to see the bug is to try to compile
java/io/FilePermission.java with `-C -O2'.

I think disabling -O with -C makes sense.  That would fix the bug,
albeit in a fragile way.

I had thought this was a must-fix bug for gcc 3.0.  But maybe it isn't
that important, as we have a simple workaround (don't use -O).

Per> A simple version of constant-folding can probably be made part of
Per> java_complete_lhs fairly easily.

The reason I mention a Java-specific fold() is that we currently don't
follow Java semantics about compile-time constants.  We need to do
this eventually.  Last time I looked, this was the single biggest
cause for gcj failures against Jacks.  This would fix the problem
we're seeing here as a side-effect.

We'd might still want to run the real fold() when not generating
bytecode.  It does a lot of optimizations which are presumably useful,
and which we wouldn't want to duplicate.  OTOH I don't know whether
fold() ever breaks Java semantics when optimizing.

Tom