On 12/9/25 10:01 AM, Konstantinos Eleftheriou wrote:
The call to `gen_lowpart` in `store_bit_field_1` might copy the destination
register into a new one, which may lead to wrong code generation, as the bit
insertions update the new register instead of updating `str_rtx`.
This patch copies back the new destination register into `str_rtx` when needed.
gcc/ChangeLog:
* expmed.cc (store_bit_field_1): Copy back the new destination
register into `str_rtx` when needed.
Ugh. gen_lowpart would not be a routine I'd want to see in this call
chain. Largely because it's hooked and thus the underlying
implementation changes depending on where in the pipeline we are there's
also various helpers that tend to get used. Sigh.
Regardless something doesn't make sense with your patch. The existing
code passes the return value from gen_lowpart (potentially the new
pseudo) as the destination for store_integral_bit_field.
It seems like the problem would be inside store_integral_bit_field or
its children. store_integral_bit_field doesn't have the problematic
semantics (it returns a bool, not an RTX, so by definition it doesn't
have those problem semantics).
I'm thinking I really should throw this under the debugger to understand
the dataflow here. How can I trigger the underlying issue?
jeff
