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
