Re: RFA: fix PR tree-optimization/28144

[Joern RENNECKE <joern.rennecke@st.com>]

Roger Sayle wrote:

>  
>
>The preferred "((unsigned HOST_WIDE_INT) 1 << 31) - 1", or even just the
>less ideal "(1UL << 31) - 1", doesn't invoke undefined behaviour and is
>the correct idiom used elsewhere in GCC.
>
Yes, that makes sense.

(FWIW, the reason why the incorrect high word didn't cause test failures 
in the orgininal
 patch was because I had assumed big endian argument passing, while 
real_from_integer
 actually has the lowpart argument first.  Which also goes to show that 
the interesting cases
 are not values in excess of the int range, but ones that fint into 
ints, but not (unsigned)
char / short.   

>Now you're showing your age.  :-) Since 4.0, GCC has tree-ssa optimizers
>and testsuite infrastructure to scan tree dumps that can be used to
>check the results of tree-level optimizations without worrying about
>the target's assembly language and/or RTL expanders.
>  
>
I'll look into this once we get back into bootstrapland...

>I believe this issue can/should probably be fixed in the Java front-end
>by construcing tree's that cast floating point types to integer types
>narrower than an int, by first casting to "int".  As you hint yourself,
>this will also avoids problems on target hardware that may choose to
>use different "undefined" behaviour to implement ufixdfqi2.
>
The common case is that there is no specific fix{uns}_trunc[sd]f[qh]i2 
expander,
and the fix[sd]fsi2 expander is used, followed by a narrowing conversion;
the latter is a no-op if TRULY_NOOP_CONVERSION allows this, otherwise it
is generated with a truncsi[qh]i2 expander.


> 
>"(byte)300.0" is undefined in C and may be implemented in different ways
>on different hardware, 
>
But it practice you get 44 most or all of the time when doing it on 
hardware.
Giving a different result when optimizing is unhelpful.

>but java's intended "(byte)(int)300.0" is
>well-defined and portable.
>
>By not fixing this is in the Java front-end, the code you're changing
>only addresses the problem of compile-time conversions, leaving the
>deeper issue of run-time conversion unresolved/broken.
>  
>
No, as stated above, the run-time conversion usually behaves just like 
java for
numbers that can be represented as ints.
Before the saturating code was added to fold-const.c, this was also true 
for the
compile-time conversions, thus allowing people to debug their programs 
at -O0.
Now people have to debug their programs with optimizations, which can get
really ugly when the constant folding is only triggered at -O3.

>This would also prevent Java's distintion between types less than
>32-bits from those greater than 32-bits from leaking into the middle-end,
>which may be counter intuitive semantics on 64-bit or 16-bit targets
>in different front-ends.
>  
>
What we currently have is a buggy java conversion code having leaked 
into the
middle-end, making the results counter intuitive on all targets.
It would certainly be nice if we could get this consistent for all 
targets, but this
would require a language callback.  If we want to prevent global language
selection, that would mean that either a callback, the intermediate 
conversion type,
its size, or the context langugae would have embedded into the node 
which causes
the conversion.
I suppose encoding the language in the node is best, because this allows 
to use
a relatively small bitfield, and this can the be used as an index into 
an array
of structures describing the frontend languages, so this would also be a 
very
general mechanism which can be applied to all nodes that have some
language-specific behaviour (this is not a property of the function because
in the future, different conversions could be inlined from functions 
written in
different languages).

>I'm not strongly opposed to refining the middle-end's FIX_TRUNC_EXPR
>semantics, but as shown, tweaking fold-const.c is trickier and riskier
>than fixing the more fundamental problem in the java front-end.
>  
>
If you want to fix it in the java front end, then we should back out the 
java saturation
code from fold-const.c.  This would also get rid of the regression we 
have with
usability of our compiler for debugging C code.