[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law law at redhat dot com --- Bernd, need your input on the best direction here... This BZ is caused by mis-handling of SCHED_GROUP_P in some scheduler work from a few years ago (meaning it's probably a 4.8 and 4.9 regression as well). The offending commit is : Author: bernds bernds@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Apr 1 17:48:35 2011 + * haifa-sched.c (prune_ready_list): New function, broken out of schedule_block. (schedule_block): Use it. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171845 138bc75d-0d04-0410-961f-82ee72b054a4 As can be seen in this BZ, it can cause incorrect code anywhere we use SCHED_GROUP_P to keep insns together for correctness. It can cause missed-optimizations for things like insn fusion. The old code would just advance the cycle counter forward the appropriate number of cycles when it saw a SCHED_GROUP_P insn. I can hack something together to have a similar effect here, but I'm unsure if it would break the tic6x.
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 --- Comment #9 from Mikael Pettersson mikpelinux at gmail dot com --- This wrong-code started with Bernd's r171845, possibly by exposing a latent issue.
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 --- Comment #8 from Andreas Schwab sch...@linux-m68k.org --- *** Bug 64233 has been marked as a duplicate of this bug. ***
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 --- Comment #7 from Jonathan Larmour jifl-bugzilla at jifvik dot org --- I have also now submitted bug 64233 which is about a different testcase which also gets misoptimised. This may or may not be related, but could well be since -fschedule-insns is what makes a difference, and a 'tst' disappears (although there may be more going wrong with that testcase). Hopefully this will make it easier for someone to work on fixing this, which I would be very grateful for! Right now, I can't consider the coldfire tools robust enough to safely use for production code which is unfortunate :-(. So if anyone could spend some time looking at this bug or bug 64233, that would be great, thanks!
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Andreas Schwab sch...@linux-m68k.org --- It disappears in the IRA pass.
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 --- Comment #4 from Jonathan Larmour jifl-bugzilla at jifvik dot org --- I have just double-checked, and my gcc 4.8.3 definitely doesn't generate the 'tstl', but it looks like you're bang on right about how gcc was configured: I configured it with --with-arch=cf. Sorry I should have realised the importance of this before and included it! So I think you should be able to reproduce it if you add -mcpu=5206 (or any other coldfire cpu) to the compile line.
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- I can reproduce, choosing a CF family cpu causes the needed tstl to disappear.
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 --- Comment #3 from Mikael Pettersson mikpelinux at gmail dot com --- I can't reproduce with a vanilla gcc-4.8.3 configured for m68k-elf. For the if (0x0 == haddr) ... it generates: lea (20,%sp),%sp tst.l %d2 seq %d2 extb.l %d2 neg.l %d2 which looks correct and matches your 4.7 output. How was your gcc configured?
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Jonathan Larmour jifl-bugzilla at jifvik dot org changed: What|Removed |Added Known to fail||4.8.3 --- Comment #2 from Jonathan Larmour jifl-bugzilla at jifvik dot org --- (In reply to Andreas Schwab from comment #1) GCC 4.7 is no longer maintained. Please try to reproduce it with a newer version. I can now confirm that it also reproduces equally with gcc 4.8.3. I haven't tried 4.9 (it was enough of a job getting 4.8 built!).
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-23 Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- GCC 4.7 is no longer maintained. Please try to reproduce it with a newer version.
