This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: HARD_REGNO_CALL_PART_CLOBBERED question (PR53595)
On Mon, 11 Jun 2012, Georg-Johann Lay wrote:
> Hans-Peter Nilsson wrote:
> > On Fri, 8 Jun 2012, Georg-Johann Lay wrote:
> >> I observed that HARD_REGNO_CALL_PART_CLOBBERED gets called with
> >> hard registers that HARD_REGNO_MODE_OK would reject.
> >>
> >> Is it save to set HARD_REGNO_CALL_PART_CLOBBERED to FALSE for
> >> hard registers for which HARD_REGNO_MODE_OK is FALSE?
> >
> > IMHO it shouldn't matter. It seems like a bug that
> > HARD_REGNO_CALL_PART_CLOBBERED is called then.
> > Maybe an even more sinister bug is the cause?
>
> In fact it matters, see http://gcc.gnu.org/PR53595
Maybe I wasn't clear enough: if it matters, IMHO it's a bug in
the middle-end / register allocator. I just wanted to point in
that direction before you go working around it in the port.
> What's even more strange is that the fix in PR53595
> (return 0 for H_R_C_P_C if !H_R_M_OK) can also fix
> http://gcc.gnu.org/PR53615
>
> At least it makes PR53615 no more pop up with the patch.
>
> But from what I see with PR53615 it appears to be some
> memory hog or buffer overflow or similar that leads
> to this strange artifact.
Only gdb can tell. :]
> > (Like the one D.J. is/was on to recently.)
> >
> > brgds, H-P
>
>
> It there a PR? Or changes that went upstreamm after SVR 188257,
> i.e. after the first 4.7.1 release candidate was rolled?
I don't think so; CCing him. Not that every weird bug or
stack overwrite is the same but whatever...
brgds, H-P