[Bug target/48990] New: MIPS wrong code error with -O1

[Bug target/48990] New: MIPS wrong code error with -O1

[pkoning at gcc dot gnu.org]

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

           Summary: MIPS wrong code error with -O1
           Product: gcc
           Version: 4.5.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pkoning@gcc.gnu.org


Created attachment 24241
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24241
preprocessed file (trimmed a bit) that reproduces the bug

The attached file compiles wrong code with -march=xlr -msoft-float -mabi=n32
-O1.  It compiles correctly with -O2.

The error shows up in basic block 3: the branch (beql $2,$0,$L10) has a li
$4,32 in its delay slot.  That clobbers $4 (A0) in the no-branch case, and A0
is still needed a few lines below.

The bug is also present in GCC 4.5.1

In looking at the debug dumps, I see the problem introduced in the "mach" pass
-- that pass builds a sequence insn for the branch and the load.

I'll try 4.6.0 next.

[Bug target/48990] MIPS wrong code error with -O1

[pkoning at gcc dot gnu.org]

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

--- Comment #1 from Paul Koning <pkoning at gcc dot gnu.org> 2011-05-13 16:40:55 UTC ---
GCC 4.6.0 gets it wrong also, in exactly the same way.

[Bug target/48990] MIPS wrong code error with -O1

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-05-13 17:49:28 UTC ---
>That clobbers $4 (A0) in the no-branch case
No it does not as beql is a branch likely instruction and the delay slot only
happens when the branch is taken.

[Bug target/48990] MIPS wrong code error with -O1

[pkoning at gcc dot gnu.org]

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

--- Comment #4 from Paul Koning <pkoning at gcc dot gnu.org> 2011-05-13 18:16:11 UTC ---
Re comment 2: Sorry, my typo, I incorrectly transcribed the .s file.  It's a
beq, not a beql.

[Bug target/48990] MIPS wrong code error with -O1

[pkoning at gcc dot gnu.org]

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

--- Comment #3 from Paul Koning <pkoning at gcc dot gnu.org> 2011-05-13 18:14:00 UTC ---
The problem also shows up with -mabi=64, but it works correctly for -mabi=32
and -mabi=o64.

[Bug target/48990] MIPS wrong code error with -O1

[pkoning at gcc dot gnu.org]

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

--- Comment #5 from Paul Koning <pkoning at gcc dot gnu.org> 2011-05-13 18:20:42 UTC ---
Created attachment 24242
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24242
Assembly output from -mabi=n32 case, GCC 4.5.1

Here is the assembly file (with -dA so basic block boundaries are marked).  The
offending instruction is the last one in BB 3; the instruction that requires
the original value from A0 is the last one in BB 4.

[Bug target/48990] MIPS wrong code error with -O1

[pkoning at gcc dot gnu.org]

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

--- Comment #6 from Paul Koning <pkoning at gcc dot gnu.org> 2011-05-13 20:29:50 UTC ---
Created attachment 24243
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24243
debug dump from the pass before machdep

After some debugging, I see that the problem is that register 4 (A0) is marked
dead in the prologue, and then afterwards is still used.  This causes the delay
slot fill logic to believe it can put li $4,32 into the delay slot -- because
it appears not to be needed.

So the question now is why that register is marked dead and still used.

[Bug target/48990] MIPS wrong code error with -O1

[pkoning at gcc dot gnu.org]

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

Paul Koning <pkoning at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #7 from Paul Koning <pkoning at gcc dot gnu.org> 2011-05-14 01:57:26 UTC ---
It appears I misread the assembly output for 4.5.3.  Applying the fix for
PR/42775 to my 4.5.1 sources fixed this issue.

*** This bug has been marked as a duplicate of bug 42775 ***