[Bug c/38644] New: Optimization flag -O1 -fschedule-insns2 causes wrong code

[Bug c/38644] New: Optimization flag -O1 -fschedule-insns2 causes wrong code

[davejmurphy at me dot com]

The -fschedule-insns2 optimisation causes wrong code to be emitted for the
following testcase. The assembly code loads a value from a stack frame which
has already been deallocated.

This is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282 for
powerpc-eabi.

extern int doStreamReadBlock(int *, char *, int size, int);

char readStream(int *s)
{
    char c = 0;
    doStreamReadBlock(s, &c, 1, *s);
    return c;
}

arm-eabi davem$ arm-eabi-gcc -v -O2 -mthumb -c test.c 
Using built-in specs.
Target: arm-eabi
Configured with: ../../gcc-4.3.2/configure --enable-languages=c,c++
--with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc
--with-gnu-ld --with-gnu-as --disable-shared --disable-threads
--disable-win32-registry --disable-nls --disable-debug --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch --target=arm-eabi
--with-newlib --prefix=/opt/devkitpro/devkitARM
--with-bugurl=http://wiki.devkitpro.org/index.php/Bug_Reports
--with-pkgversion='devkitARM release 24'
Thread model: single
gcc version 4.3.2 (devkitARM release 24) 

00000000 <readStream>:
   0:   b510            push    {r4, lr}
   2:   b082            sub     sp, #8
   4:   466c            mov     r4, sp
   6:   3407            adds    r4, #7
   8:   2300            movs    r3, #0
   a:   7023            strb    r3, [r4, #0]
   c:   1c21            adds    r1, r4, #0
   e:   6803            ldr     r3, [r0, #0]
  10:   2201            movs    r2, #1
  12:   f7ff fffe       bl      0 <doStreamReadBlock>
  16:   b002            add     sp, #8          <--- stack frame deallocated
  18:   7820            ldrb    r0, [r4, #0]    <--- value loaded from stack
frame
  1a:   bc10            pop     {r4}
  1c:   bc02            pop     {r1}
  1e:   4708            bx      r1

The same thing happens with mainline

 /opt/devkitpro/devkitARM_mainline/bin/arm-eabi-gcc -v -O2 -mthumb -c test.c 
Using built-in specs.
Target: arm-eabi
Configured with: ../../../gcc_mainline/configure --disable-nls
--target=arm-eabi --prefix=/opt/devkitPro/devkitARM --enable-languages=c,c++
--with-cpu=arm7tdmi --enable-interwork --enable-multilib --with-gcc
--with-gnu-ld --with-gnu-as --disable-shared --disable-threads
--disable-win32-registry --disable-nls --disable-debug --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libstdcxx-pch
Thread model: single
gcc version 4.4.0 20081223 (experimental) (GCC) 

00000000 <readStream>:
   0:   b510            push    {r4, lr}
   2:   b082            sub     sp, #8
   4:   466c            mov     r4, sp
   6:   3407            adds    r4, #7
   8:   2300            movs    r3, #0
   a:   7023            strb    r3, [r4, #0]
   c:   1c21            adds    r1, r4, #0
   e:   6803            ldr     r3, [r0, #0]
  10:   2201            movs    r2, #1
  12:   f7ff fffe       bl      0 <doStreamReadBlock>
  16:   b002            add     sp, #8
  18:   7820            ldrb    r0, [r4, #0]
  1a:   bc10            pop     {r4}
  1c:   bc02            pop     {r1}
  1e:   4708            bx      r1


-- 
           Summary: Optimization flag -O1 -fschedule-insns2 causes wrong
                    code
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: davejmurphy at me dot com
 GCC build triplet: i386-apple-darwin9.6.0
  GCC host triplet: i386-apple-darwin9.6.0
GCC target triplet: arm-none-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug c/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[davejmurphy at me dot com]

------- Comment #1 from davejmurphy at me dot com  2008-12-27 22:10 -------
Created an attachment (id=16993)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16993&action=view)
preprocessed source for arm-eabi testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug target/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[rearnsha at gcc dot gnu dot org]

------- Comment #2 from rearnsha at gcc dot gnu dot org  2009-03-17 00:03 -------
Confirmed, this is a nasty bug that might silently bite users after a long
period of apparently correct operation.


-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org, ramana dot r at gmail
                   |                            |dot com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Priority|P3                          |P2
   Last reconfirmed|0000-00-00 00:00:00         |2009-03-17 00:03:45
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug target/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2009-11-23 16:42 -------
*** Bug 42155 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |heavy at smtp dot ru


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug target/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2009-12-21 21:46 -------
*** Bug 42452 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cwang at rossvideo dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[rearnsha at gcc dot gnu dot org]

------- 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

[steven at gcc dot gnu dot org]

------- 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

[rearnsha at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[rearnsha at gcc dot gnu dot org]

------- 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

[steven at gcc dot gnu dot org]

------- 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

[cwang at rossvideo dot com]

------- 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

[pinskia at gcc dot gnu dot org]

------- 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

[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[pinskia at gcc dot gnu dot org]

------- 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

[sebastian dot huber at embedded-brains dot de]

------- 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

[mikpe at it dot uu dot se]

------- 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=20749&action=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

[mikpe at it dot uu dot se]

------- 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

[sebastian dot huber at embedded-brains dot de]

------- 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

[sebastian dot huber at embedded-brains dot de]

------- 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
        strb    r3, [r4, #7]
        add     r4, r4, #7
        ldr     r3, [r0]
        mov     r1, r4
        mov     r2, #1
        bl      doStreamReadBlock
        add     sp, sp, #8
        ldrb    r0, [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] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[steven at gcc dot gnu dot org]

------- Comment #19 from steven at gcc dot gnu dot org  2010-08-12 10:00 -------
According to comment#14, a patch from Alexander Monakov introduced this bug,
therefore:

1. this is a regression on a primary platform => priority should be set P1


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org, amonakov at gcc dot gnu
                   |                            |dot org
            Summary|Optimization flag -O1 -     |[4.3/4.4/4.5/4.6 Regression]
                   |fschedule-insns2 causes     |Optimization flag -O1 -
                   |wrong code                  |fschedule-insns2 causes
                   |                            |wrong code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[steven at gcc dot gnu dot org]

------- Comment #20 from steven at gcc dot gnu dot org  2010-08-12 10:00 -------
...and
2. Add richi and amonakov to CC:


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[steven at gcc dot gnu dot org]

------- Comment #21 from steven at gcc dot gnu dot org  2010-08-12 10:08 -------
Re. comment #14 "I am a bit irritated why this bug survived the 4.4.0
and 4.5.0 release.": Yes, well, ARM maintainers have been in the CC-list for
this bug since the beginning, and apparently it was even too much trouble for
them to see if this is a regression or not... :-(

Anyway, many thanks to Sebastian Huber for identifying the revision that
introduced (or exposed) this bug.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2009-12-22 11:16:40         |2010-08-12 10:08:35
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[amonakov at gcc dot gnu dot org]

------- Comment #22 from amonakov at gcc dot gnu dot org  2010-08-12 10:12 -------
It looks like patch from comment #16 should fix the problem, but was not
reviewed and/or applied.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[steven at gcc dot gnu dot org]

------- Comment #23 from steven at gcc dot gnu dot org  2010-08-12 11:37 -------
The patch from comment #16 only fixes the symptom, and only on ARM. It is not a
proper fix for the generic problem that is apparently also visible on POWER.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[jakub at gcc dot gnu dot org]

------- Comment #24 from jakub at gcc dot gnu dot org  2010-08-12 11:47 -------
It is not visible on POWER, because it has been fixed there.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[amonakov at gcc dot gnu dot org]

------- Comment #25 from amonakov at gcc dot gnu dot org  2010-08-12 12:00 -------
(In reply to comment #23)
> The patch from comment #16 only fixes the symptom, and only on ARM. It is not a
> proper fix for the generic problem that is apparently also visible on POWER.

PR30282 audit trail contains more discussion of this problem.  Jim Wilson
argues that this problem should be addressed by emitting stack ties in
epilogues for targets that suffer from this problem (other targets apparently
do not thanks to red zone).  POWER was fixed that way (PR44199).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2010-08-12 12:04 -------
(In reply to comment #19)
> According to comment#14, a patch from Alexander Monakov introduced this bug,
> therefore:
> 
> 1. this is a regression on a primary platform => priority should be set P1

It's not P1 because P1 is reserved for serious bugs that were never in any
release which isn't true here.  P1 _block_ a release, it is unreasonable
to do so in general if a previous release shipped with that bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[rearnsha at gcc dot gnu dot org]

------- Comment #27 from rearnsha at gcc dot gnu dot org  2010-08-12 12:13 -------
(In reply to comment #21)
> Re. comment #14 "I am a bit irritated why this bug survived the 4.4.0
> and 4.5.0 release.": Yes, well, ARM maintainers have been in the CC-list for
> this bug since the beginning, and apparently it was even too much trouble for
> them to see if this is a regression or not... :-(
> 
> Anyway, many thanks to Sebastian Huber for identifying the revision that
> introduced (or exposed) this bug.
> 

So this ARM maintainer, proposed a fix for the problem (a generic bug, not a
back-end bug).  But because it seems that generating correct code on all
targets isn't a priority, it was rejected.

The compiler shouldn't be generating unsafe code by default; back-ends
shouldn't need to paper over bugs in the MI code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[jakub at gcc dot gnu dot org]

------- Comment #28 from jakub at gcc dot gnu dot org  2010-08-12 12:26 -------
The problem is that stuff like red-zone presence and size isn't known to the
middle-end, all that stuff is backend private, so I think the right way is to
handle this in the backends and most of the backends managed to handle it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[rearnsha at gcc dot gnu dot org]

------- Comment #29 from rearnsha at gcc dot gnu dot org  2010-08-12 12:30 -------
(In reply to comment #28)
> The problem is that stuff like red-zone presence and size isn't known to the
> middle-end, all that stuff is backend private, so I think the right way is to
> handle this in the backends and most of the backends managed to handle it.
> 

No, the middle end code must fail safe.  If targets don't need that, then they
should have the ability to turn it off; not the other way around.

This is critical because it leads to silent failures otherwise.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[rguenth at gcc dot gnu dot org]

------- Comment #30 from rguenth at gcc dot gnu dot org  2010-08-30 15:48 -------
A regression but no known-to-work version?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.3.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[mikpe at it dot uu dot se]

------- Comment #31 from mikpe at it dot uu dot se  2010-08-30 18:59 -------
(In reply to comment #30)
> A regression but no known-to-work version?

4.2.4 is known to work.  See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091#c5


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #34 from Jeffrey A. Law <law at redhat dot com> 2011-02-07 16:27:24 UTC ---
Typically the right thing to do is to block all memory motions across a change
in the stack pointer.    It's somewhat overly pessimistic, but in reality the
few motions lost aren't going to be performance critical.

In the past each backend has emitted the blockage/barrier and it typically
happened soon after the port was converted to use RTL prologues/epilogues... 
That's probably the main reason why this was never fixed in the scheduler
itself -- the first couple ports emitted a blockage and after that it became
normal practice.

I would support both emitting the suitable blockage insn in the ARM backend or
adding a dependency between the stack pointer adjustment insn and all memory
insns in the scheduler.  Either is IMHO acceptable given history.  The first
would be slightly preferred during this late stage of development with the
latter being more appropriate in early stage development.

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[joel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

Joel Sherrill <joel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |

--- Comment #33 from Joel Sherrill <joel at gcc dot gnu.org> 2011-01-31 21:26:08 UTC ---
Any chance this can get some attention before 4.6 branches?  Please.

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.huber@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

--- Comment #32 from Sebastian Huber <sebastian.huber@embedded-brains.de> 2010-09-30 15:36:02 UTC ---
Which target milestone do you intend for a fix?  It is still present in 4.6.0
20100925.