Re: java.lang.StrictMath

[Tom Tromey <tromey at redhat dot com>]

I've removed the Classpath list and other innocent bystanders from the
CC line.

Bryce> Do you have any examples of how GCC is *not* strictfp compliant
Bryce> (at least on common platforms)? My understanding is that, by
Bryce> default, it tries to be strictly IEEE 754. On x86 it will store
Bryce> values to memory and make a function call to do FP arithmetic,
Bryce> unless -ffast-math is given which allows it to do inline math
Bryce> using (the 80-bit x87) FP registers.

I don't have examples.

Do we always compute compile-time constants in strict mode?  That
would be one thing to investigate.

I guess Math.max (etc) inlining is always ok since Math is not strict.

I know we accept `strictfp' as a keyword.  But I think we ignore it.
So this might mean that the `gcj -C' output will be wrong (I haven't
checked).  Also I think the interpreter doesn't recognize `strictfp'.
The interpreter just uses the C++ math operators (e.g., `*'), so here
we're at the mercy of what C++ is doing (we don't seem to pass
-ffloat-store to g++ invocations).  We could just make the interpreter
always be strict; it is slow enough that recognizing a non-strict
context probably wouldn't really help.

So maybe we're much closer than I thought.  That's cool.

Bryce> So, unless I misunderstand something and there is more to it,
Bryce> we should make -ffast-math the default for Java except where
Bryce> strictfp is encountered.

I don't know whether gcc can even handle this.  The setting has to be
context-sensitive and only set in certain classes or methods.  This
becomes really problematic if we decide to inline across such a
boundary (we could either disallow this or simply force strict fp, I
suppose).  This is something I raised with Diego for inclusion into
the new AST code.  I think the current idea is there would be separate
fp operators for each mode; we'd just have to generate the correct
trees depending on context.  Unfortunately I seem to always be 6 weeks
away from looking at the AST branch.  (And yesterday I had to delete
my copy of the branch to free some temporary disk space.)

Tom