[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2021-05-04 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Richard Biener  changed:

   What|Removed |Added

  Known to fail||8.4.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #22 from Richard Biener  ---
Fixed.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2021-05-04 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

--- Comment #21 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:b7bdb6462bb171102bada0579981e2bdbe813b21

commit r8-10940-gb7bdb6462bb171102bada0579981e2bdbe813b21
Author: Jeff Law 
Date:   Wed Apr 3 10:03:37 2019 -0600

re PR rtl-optimization/81025 (gcc ICE while building glibc for MIPS
soft-float multi-lib variant)

2019-04-03  Jeff Law  

PR rtl-optimization/81025
* reorg.c (skip_consecutive_labels): Do not skip past a BARRIER.

(cherry picked from commit 9427422ddacdf1c2914adfb6e8edca87f250fdfc)

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2020-03-04 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.4 |8.5

--- Comment #20 from Jakub Jelinek  ---
GCC 8.4.0 has been released, adjusting target milestone.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2019-04-14 Thread graham.stott at btinternet dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

--- Comment #19 from graham.stott at btinternet dot com ---
JeffThere's trival error in gcc/config/mips/mti-linux.h which causes loads of
warnings everytime it's includedThere's a missing space between a string and
MACRO about line 28Graham





 Original message 
From: law at redhat dot com  
Date: 03/04/2019  06:00  (GMT+00:00) 
To: gcc-bugs@gcc.gnu.org 
Subject: [Bug rtl-optimization/81025] [8/9 Regression] gcc ICE while building
glibc for MIPS soft-float multi-lib variant 

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025Jeffrey A. Law  changed:   What    |Removed
|Added
  Priority|P3  |P2 Status|WAITING  
  |NEW   Assignee|unassigned at gcc dot gnu.org 
|law at redhat dot com--- Comment #16 from Jeffrey A. Law  ---In response to c#10 and c#11.  I suspect you're not able to trigger
thefailures because of something in auto-host.h.  If I first configure &
installbinutils for the target (mips-mti-linux-gnu), then configure gcc for the
sametarget I can trigger the failures per the instructions in this BZ.What I'm
unable to figure out is my own comment WRT FRAME_RELATED_P from lastyear.  I
don't see any evidence this is at all related to FRAME_RELATED_P insnsin delay
slots.AFAICT we've done shrink wrapping on this case.  ISTM there's multiple
paths tothe epilogue, some save r16/r17 and adjust the stack pointer, others do
not(according to my reading of the dwarf2cfi pass RTL dump).  Thus triggering
theCFI failure due to the inconsistency (not to mention bogus code).So of
course the next thing to do is look at the prologue/epilogue dump andeverything
looks fine there.  Things also look fine at the .barriers dump. Then reorg
comes along and mucks things up horribly.The bug here is in reorg and its
legacy of trying to compensate for the lack ofa CFG.  In particular it has a
function skip_consecutive_labels.  The idea (ofcourse) is to have jumps target
the last label if there's several in a row. The code looks something like this:
 for (insn = label; insn != 0 && !INSN_P (insn); insn = NEXT_INSN (insn))    if
(LABEL_P (insn))  label = insn;THe loop termination condition allows the
code to look through notes and otherrandom crud.Now imagine if we
have(code_label 1)(barrier)(code_label 2)(more code)The BARRIER after a
CODE_LABEL can occur due to __builtin_unreachable.If a jump targets code_label
1, it will be redirected to code_label 2.  That'sfine from a runtime
standpoint, but runs afoul of the CFI bits.  Why?Consider if the jump which
targeted label 1 did not have a prologue (we'reshrink wrapping) and "more code"
section is a shrink wrapped epilogue.The original paths to code_label 2 will
have one CFI state while the new pathsto code_label 1 will have a different CFI
state and we trip the check.I'm spinning a fix overnight.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2019-04-03 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[8/9 Regression] gcc ICE|[8 Regression] gcc ICE
   |while building glibc for|while building glibc for
   |MIPS soft-float multi-lib   |MIPS soft-float multi-lib
   |variant |variant

--- Comment #18 from Jeffrey A. Law  ---
Fixed on the trunk.  Backporting to gcc-8 would be trivial, but I'm not sure
it's worth the effort.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2018-02-11 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #12 from Jeffrey A. Law  ---
I'm really starting to think we ought to just handle RTX_FRAME_RELATED_P for
delay slots in a generic way rather than forcing each backend to do it.  I'm
pretty sure that's the problem here as well as with at least one of the SH
bugs.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2017-12-19 Thread aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-12-19
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Aldy Hernandez  ---
I cannot reproduce the testcase on comment 4 either on trunk or at r247049.

abulafia:/build/t/gcc$ ./cc1 -O2 -msoft-float -mabi=32 b.c  -std=gnu11
-fgnu89-inline  -O2 -fmerge-all-constants -fno-stack-protector -frounding-math
-g -I/tmp -quiet
abulafia:/build/t/gcc$ 

This is for a cross built with:

/dir/configure --target=mips-mti-linux-gnu --enable-languages=c
--disable-decimal-float --with-mips-plt

Doug could you please reconfirm with the latest attachment in comment 4?

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2017-11-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Can't reproduce with current trunk, at least not on the #c4 testcase.
Generally, if delay slots contain frame related instructions it is always a
problem how to express that in the unwind info which doesn't have a concept of
delay slots or something similar.

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2017-06-10 Thread doug.gilmore at imgtec dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

--- Comment #9 from Doug Gilmore  ---
> I bet this is a bug in reorg.c.  It is the least used code (major
> target usage: MIPS and sparc only) and also one of the more buggy
> code.
You're right, compiling with -fno-delayed-branch doesn't tickle the bug.

Thanks!

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2017-06-10 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||wrong-debug
 Target||Mips
  Component|tree-optimization   |rtl-optimization
   Target Milestone|--- |8.0

--- Comment #8 from Andrew Pinski  ---
I bet this is a bug in reorg.c.  It is the least used code (major target usage:
MIPS and sparc only) and also one of the more buggy code.