[Bug tree-optimization/94506] New: broken code generate on MIPS

[Bug tree-optimization/94506] New: broken code generate on MIPS

[gcc@hauke-m.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506

            Bug ID: 94506
           Summary: broken code generate on MIPS
           Product: gcc
           Version: 8.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc@hauke-m.de
  Target Milestone: ---

Since we upgraded from GCC 8.3.0 to GCC 8.4.0 in OpenWrt the Linux kernel
crashes on some ath79 (MIPS BE 74Kec) boards with such a error reproducible:

[    0.084927] pid_max: default: 32768 minimum: 301
[    0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes,
linear)
[    0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes,
linear)
[    0.107070] Kernel panic - not syncing: Unexpected DSP exception
[    0.113470] Rebooting in 1 seconds..


I bisected it to change r278587 in GCC. When I revert this change the kernel
boot up fine.

We see this problem only in the Linux kernel since this commit:
https://git.kernel.org/linus/9012d011660ea5cf2a623e1de207a2bc0ca6936d

I got reports of the same problem in GCC 9.2.0, in GCC 9.3.0 it works for me
and others.

Here is the related OpenWrt Ticket:
https://bugs.openwrt.org/index.php?do=details&task_id=2928

Here is a Linux kernel binary compiled with GCC 8.4.0
https://hauke-m.de/files/vmlinux.debug-new-5.4-8.4.0.broken

Here is a Linux kernel binary compiled with GCC 8.4.0 + r278587 reverted:
https://hauke-m.de/files/vmlinux.debug-new-5.4-8.4.0.working

I was unable to go into the details what is different between these two
compiles.

[Bug target/94506] broken code generate on MIPS

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-04-07
             Status|UNCONFIRMED                 |WAITING
          Component|tree-optimization           |target
             Target|                            |mips
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The rev in question merely changes a heuristic and thus we likely trigger a
latent issue now.  I expect the kernel change to have a quite big effect
on code-generation noise-wise so inspecting code differences for the GCC
change is probably easier.

Without a testcase there's nothing we can do unfortunately.

[Bug target/94506] broken code generate on MIPS

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yeah, when you have the two GCC revisions, I'd suggest to save object files
from both builds and do a binary search during linking on which object file
matters (start with half *.o files built by one gcc revision and half with the
other one etc.).
Once you have (hopefully) single TU where kernel works if everything is built
by newer gcc but that single one by older gcc and doesn't work if everything is
built by older gcc but that single one by newer gcc, attach the preprocessed
source for it, both assembler outputs and say exact gcc command line.
Depending on the amount of changes in the file, we might need further bisection
using debug counters or something similar.
As Richard said, the patch fixed heuristics, so it is unlikely the bug is in
that exact change, but can be anywhere else (could be on the kernel side too).

[Bug target/94506] broken code generate on MIPS

[gcc@hauke-m.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94506

Hauke Mehrtens <gcc@hauke-m.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Hauke Mehrtens <gcc@hauke-m.de> ---
This was not a bug in GCC, but in the kernel.

The kernel was not taking care of hazards between mtc0 and mfc0, so a bit set
in the c0_status register was overwritten later on. This problem only happened
with some orderings of the instructions, this made it looks like it depends on
the GCC version.

See here for details: https://www.spinics.net/lists/stable/msg399099.html