--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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.
--
--- 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
--- 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
--- 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.
--
--- 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
--- 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
14 matches
Mail list logo
