On 9/1/25 3:53 PM, Aleksandar Rakic wrote:
Hi Jeff,
[PATCH v2 02/12] Fix unsafe comparison against stack_pointer_rtx:
https://sourceware.org/pipermail/gcc-patches/2025-March/677829.html
Is this still an issue? I thought this was fixed a while back in the
renamer. I don't necessarily thing the patch would ever do anything
wrong, but if it's still needed, then that's likely pointing at a bug
elsewhere. There is supposed to be one and only one stack pointer.
Thanks again for your feedback.
I understand your concern that this patch might be unnecessary if the
issue has already been addressed elsewhere. While investigating, I came
across several commits that seem relevant.
This is an issue that's been visited several times. I'm aware of all
the threads you referenced :-)
What you need to show for this to move forward is a path by which you
can get multiple instances of the stack pointer in practice. That's not
supposed to happen. Richard S. and I hashed through this in 2016/2017
in relation to a different set of MIPS issues.
Most notably, commit 893883f2 introduces special handling for
`stack_pointer_rtx` in `regcprop.cc`. It ensures that
`stack_pointer_rtx` is only returned when the mode matches, and avoids
modifying its attributes (`ORIGINAL_REGNO`, `REG_ATTRS`, `REG_POINTER`)
— preserving its uniqueness. This might be the fix you were referring
to, though I’m not entirely certain it covers all the cases addressed by
my patch.
I'm aware of that patch. Manolis and I worked through various issues.
The key thing to know about that patch is it does not result in multiple
instances of the stack pointer.
Additionally, commit `d60e544` explicitly states:
"We can't just compare with STACK_POINTER_RTX because the reference to
the stack pointer might be in some other mode. In particular, an
explicit clobber in an asm statement will result in a QImode clobber."
Right, but I think this just papered over the real problem that the
asm-clobber code created another instance of the stack pointer.
Jeff
