Re: RFA: fix PR tree-optimization/28144

[Joern RENNECKE <joern dot rennecke at st dot com>]

Tom Tromey wrote:

> > > > > > "Roger" == Roger Sayle <roger@eyesopen.com> 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.