|
|
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.
|
|