According to JLS 3.10.2:
http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.2
large (in the number of characters, not the value) floating-point literal
tokens must be rounded off to the nearest representable value.
The current mainline (4.1.0 20050817) does not do this. See the attached
testcase. Both Jikes and Sun javac (1.5.0.03) correctly compile this class,
while GCJ gives:
---------------------------------- 8< ----------------------------------
~/src/tmp > $MYGCJ --syntax-only Snafu.java
Snafu.java:3: error: Numeric overflow for 'int' literal.
double foo =
3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882;
^
Snafu.java:4: error: Class or interface declaration expected.
}
^
2 errors
---------------------------------- 8< ----------------------------------
See also Jacks testcase 3.10.2-round-6 (and other such tests). Eric
Blake says:
---------------------------------- 8< ----------------------------------
>>What is the actual length of the longest of the tokens in question
>>allowed by the JLS?
>
Literal token length is technically unlimited - the longest string
possible that still parses as a floating point number without causing
overflow or underflow must be parsed as such. However, there IS a fixed
maximum length of significant characters at which the decision of which
exact 2's complement number the decimal string will round to (or can be
determined simply by scanning for the first non-zero digit after that
length); this limit is determined by the actual base-10 representation of
the 1ulp 2's complement denormal. I wrote the jacks tests in question,
which purposefully use a 800+ character mantissa of the halfway point
between the smallest two denormals, as the longest string of non-zero
characters where rounding can make a difference. I don't remember the
exact number of significant characters, but you can reverse engineer that
from the jacks test. Remember that you need to strip leading zeros of
both the mantissa and exponent before starting to count characters towards
the limit; fortunately, Java has no way to stringize a literal so you only
need to obtain the exact value rather than preserve the original string.
On the other hand, since every possible double can be expressed with a
decimal string with a maximum of 24 characters (and even fewer characters
with hex-float literals in Java 1.5 syntax), only brain-dead compiler test
suites are ever likely to give you a literal with more than 256 characters :)
---------------------------------- 8< ----------------------------------
(Ref.: http://gcc.gnu.org/ml/java-patches/2005-q3/msg00218.html)
--
Summary: Incorrect parsing and rounding off of large floating-
point literals
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmathew at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23432
