https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #18 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #17)
...
> Yes, but that says the high 48 bits of the hardware reg are untouched, which
> is not true (only the high 16 of the low 32 are guaranteed unmodified).
Right, if the original register mode does not match the mode of the full
hardreg, we continue to need that mode as the upper bound. So with the subreg
folding in reload we appear to loose information we need to interpret the
STRICT_LOW_PART correctly.
I'm testing the following patch in combination with my other fix now:
diff --git a/gcc/lra-spills.cc b/gcc/lra-spills.cc
index 4ddbe477d92..9c125a9ce38 100644
--- a/gcc/lra-spills.cc
+++ b/gcc/lra-spills.cc
@@ -855,6 +855,7 @@ lra_final_code_change (void)
for (i = id->insn_static_data->n_operands - 1; i >= 0; i--)
if ((DEBUG_INSN_P (insn) || ! static_id->operand[i].is_operator)
+ && ! static_id->operand[i].strict_low
&& alter_subregs (id->operand_loc[i], ! DEBUG_INSN_P (insn)))
{
lra_update_dup (id, i);
With that change the SUBREG folding from comment #11 happens later in final
(cleanup_subreg_operands). I'm not sure whether we would have to prevent it
there as well?!
