https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127447
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED |NEW
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
I fail to see how exactly conversions that are stripped in
decode_field_reference are supposed to be "re-applied" given that we allow both
extensions and truncations. So I'm inclined to give up for at least
sign-extensions for XOR. For truncations it might be enough to truncate
the operand, but I wonder why that would be required. The analysis suggests
we're taking *pexp at face-value, so do not expect that to have a different
than original type, but it's nowhere adjusted in decode_field_reference
so the safety net must be upthread? But I do see we do adjustments for
shifts and ands ...
The LLM suggested "fix" looks wrong:
1 diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
2 index e3df0d1163c..8e13d8f80ed 100644
3 --- a/gcc/gimple-fold.cc
4 +++ b/gcc/gimple-fold.cc
5 @@ -8067,6 +8067,9 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
*pbitsize,
6 }
7 }
8
9 + if (outer_type && TREE_CODE (exp) == INTEGER_CST)
10 + exp = fold_convert_loc (loc[0], outer_type, exp);
11 +
12 /* Identify the relevant bits. */
13 poly_int64 poly_bitsize, poly_bitpos;
14 int unsignedp, reversep = *preversep, volatilep = *pvolatilep;
Alex? I'd really appreciate if you could have a look at the various
accumulated PRs around your if-combine changes, possibly you remember some of
the details
here.
