Georg-Johann Lay writes:
> Richard Sandiford schrieb:
>> Georg-Johann Lay writes:
>>
>>>Attached you find a new, tentative patch. It resolves the issue in my
>>>small test program. However, I think someone with more insight into
>>>combine should take over the patch.
>>
>> OK, point taken :-)
Richard Sandiford schrieb:
Georg-Johann Lay writes:
Attached you find a new, tentative patch. It resolves the issue in my
small test program. However, I think someone with more insight into
combine should take over the patch.
OK, point taken :-) If you'd prefer someone else to approve it
t
Georg-Johann Lay writes:
> Richard Sandiford wrote:
>> What do you think about instead changing:
>>
>> /* If there are any volatile insns between INSN and I3, reject, because
>> they might affect machine state. */
>>
>> for (p = NEXT_INSN (insn); p != i3; p = NEXT_INSN (p))
>> if (
Richard Sandiford wrote:
> Georg-Johann Lay writes:
>> This patch fixes PR51374 by more strictly updating mem_last_set.
>> Sloppy handling of mem_last_set can lead to error in volatile correctness
>> because combine then is allowed to drag one volatile access over an other
>> volatile thing (volat
Georg-Johann Lay writes:
> This patch fixes PR51374 by more strictly updating mem_last_set.
> Sloppy handling of mem_last_set can lead to error in volatile correctness
> because combine then is allowed to drag one volatile access over an other
> volatile thing (volatile access, asm volatile, unspe
This patch fixes PR51374 by more strictly updating mem_last_set.
Sloppy handling of mem_last_set can lead to error in volatile correctness
because combine then is allowed to drag one volatile access over an other
volatile thing (volatile access, asm volatile, unspec_volatile...).
As explained in t
