[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Segher Boessenkool --- Fixed.
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Tue Oct 31 09:49:40 2017 New Revision: 254252 URL: https://gcc.gnu.org/viewcvs?rev=254252&root=gcc&view=rev Log: Subject: [PATCH] rs6000: Fix crash with big stack clash interval (PR82674) If the user asks for a stack clash probe interval of 64kB, we currently generate a "stdu rX,-65536(r1)" instruction. That instruction does not exist (the offset is a 16-bit signed number). If the offset is too big we should force it into a register and generate a "stdux rX,rY,r1" instruction, instead. PR target/82674 * config/rs6000/rs6000.md (allocate_stack): Force update interval into a register if it does not fit into an immediate offset field. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #7 from Jeffrey A. Law --- Cool. I've got systems here that are primed for testing, so if you could pass the patch along I can do spins fairly easily.
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|law at redhat dot com |segher at gcc dot gnu.org --- Comment #6 from Segher Boessenkool --- I have a patch; regchecking now.
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #5 from Jeffrey A. Law --- True that 64k may be interesting because of pagesize considerations. But I'm not sure how to make it work reliably on ppc because I'm not aware of another scratch register we can use if we have that large of a probing interval.
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #4 from Segher Boessenkool --- Yeah. The only problem is 64kB is actually an interesting case to support, since that is the page size on modern systems :-(
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #3 from Jeffrey A. Law --- So while fixing the expander that allocates dynamic space is easy. Fixing the other cases is harder, particularly since we need another scratch. Given it's always been expected that the probing internval might be limited by such things, I think it's best to just error out for too-large a probing interval.
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #2 from Jeffrey A. Law --- Right, but it's the expander to allocate dynamic space that's creating the bogus RTL. It's a trivial fix that I just need to run through some testing.
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 --- Comment #1 from Peter Bergner --- That offset is too large to fit in the stdu immed field, so it really shouldn't have been accepted by the rs6000_legitim*_ functions.
[Bug target/82674] ICE with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-10-23 CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com Ever confirmed|0 |1
