[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #15 from eweddington at cso dot atmel dot com 2007-08-23 20:39 --- Closing bug as WORKSFORME based on Bjoern's observations in comment #13. -- eweddington at cso dot atmel dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #14 from eweddington at cso dot atmel dot com 2006-09-19 20:25 --- Thanks, Bjoern, for responding in detail. If this bug cannot be reproduced, can we go ahead and close this bug report? Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #13 from bjoern dot m dot haase at web dot de 2006-09-19 20:16 --- Hello Eric, IIRC, the bug never was really resolved. The true place to fix the issue was, IMO, the most dreaded source file of the entire GCC source tree: reload. My now quite old patch tried to fix the immediate problem without touching reload and it used a fairly crude method by denying gcc to make use of Y in many situations. My test case generated code that was very difficult to handle by the register allocator. This code triggered the bug. Later on some change in some of the passes just before the 4.0.0 release removed the immediate problem. With 4.0 and afterwards I no longer succeeded to reproduce the bug: The reason might be, that the original reload bug was fixed. The reason might as well be that the reload bug is still there, but that it's no longer exposed due to some other modification in the compiler. The message is: There stand good chances that this bug is resolved, but I cannot prove it. In any case, I'd like to suggest *NOT* to make use of my old crude patch. IMO it's better to just hope that the problem is fixed. Until now, I never again stepped over this bug, so I have good confidence. HTH, Bjoern -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Comment #12 from eweddington at cso dot atmel dot com 2006-09-19 19:41 --- (In reply to comment #11) > I just realized that the patch posted here had just posted had a <= where > should have been a < for two comparisons. The patch on [EMAIL PROTECTED] > is already correct. Bjoern, 1. Is this patch already applied? 2. If yes, what versions is it applied to? 3. If no, can you post the link to the patch on gcc-patches? Or can you attach the corrected patch to this bug report? Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-09-04 11:28 --- I just realized that the patch posted here had just posted had a <= where should have been a < for two comparisons. The patch on [EMAIL PROTECTED] is already correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From giovannibajo at libero dot it 2005-09-04 11:19 --- Roger, want to have a look at this? -- What|Removed |Added CC||sayle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-09-04 10:35 --- Indeed IMHO the problem stems from the patch: +2005-01-22 Roger Sayle <[EMAIL PROTECTED]> + + PR middle-end/19378 + * config/avr/avr.c (avr_hard_regno_mode_ok): Rewrite. + IMO the problem stems from the change - /* Reload can use r28:r29 for reload register and for frame pointer - in one insn. It's wrong. We must disable it. */ - if (mode != Pmode && reload_in_progress && frame_pointer_required_p () - && regno <= REG_Y && (regno + GET_MODE_SIZE (mode)) >= (REG_Y + 1)) + /* Otherwise disallow all regno/mode combinations that span r28:r29. */ + if (regno <= (REG_Y + 1) && (regno + GET_MODE_SIZE (mode)) >= (REG_Y + 1)) return 0; Denis Chertykov's older version using "frame_pointer_required_p ()" has now vanished. A problem during register allocation has been removed by Roger Sayle's patch. However, the old frame pointer bug has been re-introduced. My suggestion is to use the following implementation. (according patch to today's head attached) This patch has passed regression tests on head without new regressions on head on the c-testsuite for compilation and simulator excecution for the atmega128. I also verified on an old snapshot that had exposed PR21990 that this patch resolves PR21990. I'll post this message also on gcc-patches. Yours, Bjoern -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-09-03 14:25 --- Hi, I now think that the true origin of this PR is related to the fact that for AVR we need *two* registers for holding the frame pointer: Recently, I have played around with modifying avr-gcc by choosing different registers for the frame pointer and the stack pointer. Namely I have experimented with the calling convention used by the IAR system (use two seperate stacks for the return addresses and data). It turned out that the stack pointer and frame pointer register number during my experiments that was used by gcc was not 28 but 29! Possibly one would have to re-investigate avr_hard_regno_mode_ok(REGNO, MODE) function in avr.c that implements the HARD_REGNO_MODE_OK target macro. IIUC, there have been a couple of problems in the past with similar results: clobbered frame pointer. Maybe the fact that this bug does not show up frequently has to do with that the constraints for the Y register implemented in avr_hard_regno_mode_ok are fairly restrictive right now, so that the register allocator and reload almost never are tempted to use it. Important information would be wether avr_hard_regno_mode_ok is evaluated dynamically for each function. In this case one could probably prevent clobbering of the frame pointer by denying any mode in regs 28 and 29 in case that a frame pointer is needed. This way one possibly could also lift the present restriction that only pointers (Pmode objects) may be held in the y register. So I think that we are right now having a hidden problem in avr-gcc that shows up only in very rare occasions. Most probably it's also present in the 3.4.4 series. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-08-20 13:49 --- I have re-investigated this bug today and observed that it no longer appears in mainline. It is also absent in today's cvs state of the 4.0 branch. Dunno whether the original problem has been fixed or whether something else has changed such that the bug is no longer exposed: Since the register allocator now seems to be smarter on both branches than it used to be, the function exposing the bug no longer needs the frame pointer. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-07-29 20:06 --- Hi, a couple of weeks after identifying this issue, I have continued working with 4.0.0. I never observed a similar failure in our production code. The issue seems to be strongly linked to the constraint requiring simultaneously two operands with the "+&" modifier. The back-end, itself never generates such a constraint pattern right now. It seems to me that the real problem has to do with register constraint matching. I personally do not have sufficient knowledge so that I would consider to start thinking about daring to eventually touch reload.c and comrades. On the other hand, I still feel uneasy about this bug. For this reason I am thinking about a workaround solely within the back-end. While refraining from requiring that code that contains the mentioned difficult constraits compiles, I presently think that one might already be better of with a situation where it triggers an ICE instead of generating wrong code. IMO, a possible workaround might be to simply disable within the machine description the move patterns that meet the two following two conditions 1.) the move uses a memory reference stored in Y 2.) the move target is the Y register itself My hope is that in absence of this move pattern, reload will no longer attempt to use the frame pointer register Y as spill register. This workaround certainly would be far from ideal, but better than nothing. I'd appreciate comments on this issue. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
-- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-15 03:22:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot haase at de dot bosch dot com 2005-06-10 12:10 --- Hi, here is the promised test case. I unfortunately had to use a number of asm statements in order to reproduce the register contraint combination exposing the bug. The test case compiles only with -morder1 (== best configuration for AVR when using many SImode variables) but ICEs otherwise. Start of testcase: // Testcase to be compiled with avr-gcc -Os -morder1 #include typedef struct { uint32_t HLFG; } special_struct; void foo3 (special_struct *a, const special_struct b) { asm ( ";" : "+r" (a->HLFG) : "r" (b.HLFG) ); } uint16_t inline static foo (const uint32_t i, const special_struct f) { uint16_t ui16_resultat; asm volatile ( ";" : "=&r" (ui16_resultat) : "r" (i), "r" (f.HLFG) ); return ui16_resultat; } special_struct inline static foo2 (const special_struct m1, const uint16_t m2) { special_struct resultat; asm volatile ( ";" : "=&r" (resultat.HLFG) : "r" (m1.HLFG), "r" (m2) ); if (m1.HLFG & 0x0002) { resultat.HLFG = ~resultat.HLFG; } return resultat; } special_struct inline static foo7 (uint16_t t) { special_struct resultat; asm volatile (";" : "=r" (resultat.HLFG):); if (t & 0x020) t = ~(t); if (t & 0x0100) { t = ~t; asm volatile (";" : "+r" (resultat.HLFG):); } asm volatile (";" : "+d" (t):); if (t > 9300) { t = 12743 - ( (int16_t) t); uint16_t ui16_r = 7480; asm volatile ( ";" : "+&r" (resultat.HLFG) : "r" (t), "r" (ui16_r) ); } else if (t > 9211) { uint16_t ui16_r = 1108; asm volatile ( ";" : "+&r" (resultat.HLFG) : "r" (t), "r" (ui16_r) ); } else { uint16_t r = 440; asm volatile ( ";" : "+&d" (resultat.HLFG), "+&r" (r) : "r" (t) ); } return resultat; } typedef struct { uint16_t q; uint16_t a; } lp_t; typedef struct { lp_t l[19]; uint32_t sf; } vmt; vmt m; special_struct sp_C[19]; special_struct problem (uint32_t s) { special_struct *p_C; special_struct ga; ga.HLFG = 0; p_C = &sp_C[0]; uint8_t lz; for (lz=0; lz < 23; lz ++) { special_struct ac; { special_struct C; C = *p_C; p_C ++; uint16_t t; t = m.l [lz].q; ac = foo7 ( foo (s, C) - t); } { uint16_t e; e = m.l [lz].a; foo3 (&ga, foo2 (ac, e)); } } return ga; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-09 22:33 --- Waiting for a testcase, it could be anything really, a target bug or even a reload one. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|critical|normal Status|UNCONFIRMED |WAITING GCC build triplet|cygwin-x86 and linux-x86| GCC host triplet|cygwin-x86 and linux-x86| Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990