Re: fold() and target-specific macros

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> I'm not sure what to do with this.  Perhaps we should really not be
Andrew> trying to do this for the Java VM, or maybe we could do something
Andrew> really simple like disabling target-specific folders when not actually
Andrew> generating target-specific code.

I think it is a mistake for us to use fold() in the front end.  Java
constant expressions are well defined by the language, platform
independent, and includes things that fold() doesn't do -- String
concatenation and using values of final variables and fields.

We've had to work around bad interactions between gcj and fold()
before; e.g., see the can_use_bit_fields_p langhook.  It seems to me
that continuing down this road will just give more problems in the
future, since first we don't know what new optimizations might be
added that will be incorrect for Java, and second since these things
are platform dependent it depends on not only better testing than we
seem to have, but also on more platforms.  For instance the bit field
thing only showed up on alpha and maybe ia64.

I think there are still Jacks failures which can be traced to our use
of fold() instead of a custom Java folder.

A Java-specific folder wouldn't be hard to write, and would insulate
us from all this.  (FWIW this is what gcjx does, and aside from some
double-to-string conversion errors, easily solved with fdlibm, I think
it is bug-free...)

Once we're past bytecode generation, and we're in generic or gimple,
then I think fold() is probably ok.  At that point we want
target-specific optimizations.  Finally, we could get rid of the bit
field langhook.

Tom