Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch compiler into ECJ using GCJ. The goal was to provide an executable form of Eclipse's compiler. Unfortunately, the effort had to be abandoned because the resulting ECJ compiler would fail the floating point section of Java Compatibility Kit (JCK).
Is this on x86 if so there is a known issue.
Subject: Re: New: Floating point in GCJ does not follow spec > > Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch > compiler into ECJ using GCJ. The goal was to provide an executable form of > Eclipse's compiler. Unfortunately, the effort had to be abandoned because the > resulting ECJ compiler would fail the floating point section of Java > Compatibility Kit (JCK). One more thing, is how did it fail? You were compiling to native, correct? Note fp is not exact unless you are using strictfp (which GCJ does not implement currently). -- Pinski
I think this is more of a duplicate of PR 10632.
(In reply to comment #0) > Eclipse's JDT/Core team was doing experiments with turning Eclipse's batch > compiler into ECJ using GCJ. The goal was to provide an executable form of > Eclipse's compiler. Unfortunately, the effort had to be abandoned because the > resulting ECJ compiler would fail the floating point section of Java > Compatibility Kit (JCK). It would be nice if you could at least indicate what kind of non-compliance you are talking of here. Is it strictfp, accuracy of results, rounding of floating-point literals, or something else? Of course, you should not reproduce tests verbatim from the JCK, but please provide some indication of what you're talking about in this bug report. For example, are you talking of JLS3 section 4.2.4 here? If yes, can you please elaborate exactly how using GCJ as the compiler to compile your compiler is affecting its status w.r.t. the JCK?
(In reply to comment #4) > > It would be nice if you could at least indicate what kind > of non-compliance you are talking of here. Is it strictfp, > accuracy of results, rounding of floating-point literals, > or something else? Of course, you should not reproduce > tests verbatim from the JCK, but please provide some > indication of what you're talking about in this bug report. Sorry, I just noticed that aph was the one who changed the summary to lack of strictfp support. So I guess he knows what you were talking about in the bug report.
gcj doesn't support strcitfp. The reserved word is allowed but ignored. The main casualty of this is x86, where we fail some tests because of excess precision.
The problem seemed to be with precision in the floating point literal. When converting a floating point literal to its double/float value, it ended up having an unexpected value.
The bug about incorrect parsing and rounding of floating-point literals is PR java/23432 and that about no support for strictfp is PR java/10632. If this bug report is about either of these, it can be closed as a duplicate of the respective previous bug. If it is about both, it can be left as a "meta bug". If it is about neither of the two, then please provide some details and change the summary appropriately.
Looking at the two other bug reports, it looks like this might be a duplicate of PR java/10632. So feel free to close is as a dup.
*** This bug has been marked as a duplicate of 10632 ***