------- Additional Comments From pmoulder at mail dot csse dot monash dot edu dot au 2004-05-12 09:19 ------- (In reply to comment #5) > Java only requires exact FP results for > strictfp classes and methods.
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#249198 says that in absense of strictfp, implementations are allowed to use {float,double}-extended-exponent numbers, which allow a wider _exponent_ range, but are still required to use the normal significand width (http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#96802). Although not completely unambiguous, the most natural reading of sections 15.17.2, 15.4 would be that {float,double} and {float,double}-extended-exponent are the _only_ value sets allowed, i.e. that gcj's behaviour on x86 is non-conforming even without strictfp. Assuming that it is desirable for gcj and other java compilers to use the target hardware's floating point implementation (typically not strictly ieee-conforming), I suggest filing a defect report with the Java Language Specification. I'm also inclined to suggest better documentation of this bug in e.g. *see (gcj)Limitations, and possibly section "What features of the Java language are/arn't (sic) supported" of FAQ.gcj. Note that this bug results in more than just being wrong in the nth digit of a calculation, but in comparisons returning the wrong result, which can result in very different branches of a program being executed (e.g. failing assertions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10632 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
