|
|
Tom Tromey wrote:
"Roger" == Roger Sayle <roger@xxxxxxxxxxxx> writes:
Roger> I believe this issue can/should probably be fixed in the Java front-end
Roger> by construcing tree's that cast floating point types to integer types
Roger> narrower than an int, by first casting to "int".
parse.y:patch_cast looks like it tries to do this.
If it is failing in some case, I'd be mildly curious to know why.
I haven't actually tested any java code.
My starting point was that I wanted to fix the C inconsistency of
different results
for different optimization options (it depends on the test case at which
optimization
level the constant folding is triggered, but for lots of cases -O0 and
-O3 are different).
The comment in fold-const.c said that the implemented semantics were
Java semantics.
Since having different behaviour for -O0 and -O3 doesn't make much sense
with the
java philosophy, I concluded that the run-time java semantics were the
same, and since
the C semantics are demonstrably different from the fold-const.c
semantics, I expected
to find some language-dependent code in the expanders. Placing the same
language-dependence into the constant folding should solve the problem.
Only, there
isn't any.
Thus, it followed that either fold-const.c or the expanders for the
runtime code had to
be doing the wrong thing for java, so I went looking what they should do.
If the java frontend makese sure that some conversions are never seen by
the constant
folder, but if the constant folder seems them, it does things that are
incorrect for java,
then certainly the comment is wrong to say that this behaviour is
required by java.
|
|