java.lang.StrictMath

Thu Feb 14 23:58:00 GMT 2002

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