------- Comment #18 from aoliva at gcc dot gnu dot org 2008-01-11 06:46 -------
I don't see anything in expand_expr_real_1 that, given something like
(wider)narrower_typed_value, would reduce the value in a way that takes the
narrower_type into account. NOP_EXPR and CONVERT_EXPR will just expand the
operand and be done with it if the modes of both types are the same and, in the
case of bitfields with the same mode but lower precision, they are.
Also, all uses of REDUCE_BIT_FIELD take only the target type into account,
which means that, if the intermediate expression wasn't reduced at the time it
was computed, then it won't ever be. And when the reduce_bit_field_operation
langhook is false, then the intermediate expression won't have been reduced at
the time it was computed. So we lose.
What I don't know is whether languages that set reduce_bit_field_operation
could expect expanders to take care of such expansions for them (they'd better,
since the need for explicit reduction code is determined by whether the value
is extracted from a bit-field in memory or held in a gimple reg that might be
the result of optimization), or they're supposed to take care of the widening
extension themselves (say, genericize (wider)unsigned_narrower_type_value as
(wider)unsigned_narrower_type_value & mask, and
(wider)signed_narrower_type_value as (((wider)signed_narrower_type_value &
mask) ^ signbit) - signbit).
Which is it? I.e., when !reduce_bit_field_operation, should
expand_expr_real_1() perform the reduction to the inner type in widening
conversions, or should convert_to_integer() take care of it when outprec >
inprec?
--
aoliva at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aoliva at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
