[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #18 from sebastian dot huber at embedded-brains dot de
2010-08-12 08:19 ---
This bug is still present in GCC 4.6.0 20100807 (arm-eabi-gcc -O1
-fschedule-insns2 -mthumb):
readStream:
push{r4, lr}
sub sp, sp, #8
mov r4, sp
mov r3, #0
strbr3, [r4, #7]
add r4, r4, #7
ldr r3, [r0]
mov r1, r4
mov r2, #1
bl doStreamReadBlock
add sp, sp, #8
ldrbr0, [r4]
@ sp needed for prologue
pop {r4}
pop {r1}
bx r1
.size readStream, .-readStream
.ident GCC: (GNU) 4.6.0 20100807 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #17 from sebastian dot huber at embedded-brains dot de 2010-06-10 07:13 --- Thank you for your investigations. A special case fix is better than nothing. I am not a GCC expert but it seems that this kind of bug appears quite regularly on different platforms and all use special case code to avoid the evil consequences. If it is a middle-end bug it should draw more attention by the middle-end developers. You cannot detect this bug through simple test cases like a flow control or math problem. With normal unit tests you will likely not find this bug in your application. You need at least two threads of execution and you have to do certain things in between a wee bit of machine instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #16 from mikpe at it dot uu dot se 2010-06-06 19:16 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00481.html I tried to use the existing stack tie instead of a full barrier, but it had no effect at all, causing the mis-schedules to reappear. I also tried to port over the PowerPC version of the stack tie, but that ICEd the compiler; I'm not yet good enough at .md hackery to resolve that one. So I went back to the initial patch, and bootstrapped and regtested it in native builds of 4.6, 4.5, and 4.4 on armv5tel-linux-gnueabi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #15 from mikpe at it dot uu dot se 2010-05-26 12:44 --- Created an attachment (id=20749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20749action=view) proposed 4.6 fix for PR38644 PR38644 and its dupes are very similar to PowerPC PR44199 and PR30282. PR44199 was recently fixed by conditionally emitting stack ties in epilogues. I first intended to simply clone that approach for Thumb1, but it turns out there's already a conditional barrier in thumb1_expand_epilogue (). So for now I simply extended that condition to also trigger whenever there's stack pointer adjustment in the epilogue. I've confirmed that this fixes the test cases in PR38644, PR42155, and PR44091. I know that Richard Earnshaw has stated that he considers this a middle-end rather than a back-end bug, and I agree with that. However, given that this wrong-code bug has been known for so long with no middle-end fix in sight, I think solving it in the back-end is appropriate for now, at least for 4.4/4.5. The current patch is a little too heavy in that it also blocks non memory accesses from being scheduled past the stack pointer adjustment -- I saw an example of that in the large PR44091 test case. Using a stack tie instead of a full barrier should hopefully fix that. So far only tested with 4.4/4.5/4.6 crosses to armv5tel-unknown-linux-gnueabi. I'll try this in a 4.5 native bootstrap soonish (4.6 bootstraps are currently broken on ARM, see PR44255). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #14 from sebastian dot huber at embedded-brains dot de 2010-05-17 09:04 --- This bug is present since r130052 which is related to: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html If this is a generic bug or not is quite irrelevant since this is a very serious bug on ARM/Thumb. I am a bit irritated why this bug survived the 4.4.0 and 4.5.0 release. In a multi threaded environment it is pretty hard to find these kind of problems. The time frame in which an interrupt can corrupt the stack frame lies between two instructions. Is -fno-schedule-insns2 a workaround for this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22 --- *** Bug 44091 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||sebastian dot huber at ||embedded-brains dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #5 from rearnsha at gcc dot gnu dot org 2009-12-22 11:16 --- IMO this is a generic bug in the scheduler. The code in sched-deps.c should note that STACK_POINTER_RTX is being changed and insert a memory barrier that prevents migration of stack-related memory accesses across the change. Of course, determining what memory accesses are stack-related is quite hard, and it may be that all memory accesses in the same address space as the stack will need to be restricted. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Component|target |rtl-optimization Last reconfirmed|2009-03-17 00:03:45 |2009-12-22 11:16:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #6 from steven at gcc dot gnu dot org 2009-12-22 11:38 --- If this is a generic bug, why are all dups of this for ARM targets? -- steven at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i386-apple-darwin9.6.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-12-22 11:58 --- (In reply to comment #6) If this is a generic bug, why are all dups of this for ARM targets? Just because it's only been reported against ARM doesn't mean it's not a generic problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-22 12:07 --- No, it likely means other backends insert memory barriers where needed themselves. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-12-22 13:33 --- I've looked at several backends and certainly not all do (sparc for example). I think they get away with it because the stack pointer is valid in all addressing constructs -- that's not true for Thumb where SP can only be used for 32-bit loads. However, that doesn't mean there isn't an underlying bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #10 from steven at gcc dot gnu dot org 2009-12-22 14:08 --- Re. #7 I'm not implying there is no generic bug. I just noticed the pattern (all reports for ARM) and thought that maybe the solution can be found in at least one of the other back ends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #11 from cwang at rossvideo dot com 2009-12-22 14:35 --- My friend also found it with powerpc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-12-22 14:58 --- (In reply to comment #11) My friend also found it with powerpc. Well some (most?) PPC ABIs there is a red zone which allows this to valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
