[Bug c/97953] New: ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[Bug c/97953] New: ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

            Bug ID: 97953
           Summary: ICE (segfault) during GIMPLE pass: loopdone compiling
                    libgcc/config/libbid/bid128_fma.c:190:1
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chris2553 at googlemail dot com
  Target Milestone: ---

Building 11-20201122 (with gcc-10-20201121 or gcc-10-20201114) results in an
ICE as follows:
/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/xgcc
-B/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
 -fno-checking -g -O2 -O2  -g -O2 -DIN_GCC    -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes
-Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition  -isystem
./include  -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../gcc-11-20201122/libgcc -I../../../gcc-11-20201122/libgcc/.
-I../../../gcc-11-20201122/libgcc/../gcc
-I../../../gcc-11-20201122/libgcc/../include
-I../../../gcc-11-20201122/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o bid128_fma.o -MT bid128_fma.o -MD -MP -MF
bid128_fma.dep -c ../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c
during GIMPLE pass: loopdone
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c: In function
'nr_digits256':
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c:190:1: internal
compiler error: Segmentation fault
  190 | nr_digits256 (UINT256 R256) {
      | ^~~~~~~~~~~~

A log of the full build (using rpmbuild) and the preprocessed source are
attached.

[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #1 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 49611
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49611&action=edit
Preprocessed source

[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #2 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 49612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49612&action=edit
Full build log

[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2020-11-23
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Can't reproduce that with c2ac0d1a66e03279.

[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #4 from Chris Clayton <chris2553 at googlemail dot com> ---
I've done a few more builds of snapshot releases of gcc-11. Using with
gcc-10-20201122, I get the ICE building 11-2020115, but 11-20201108 and
20201101 both build successfully.

[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Chris Clayton from comment #4)
> I've done a few more builds of snapshot releases of gcc-11. Using with
> gcc-10-20201122, I get the ICE building 11-2020115, but 11-20201108 and
> 20201101 both build successfully.

Can you please mention the exact git revisions as using only a datestamp still
leads to a bunch of commits?

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |tree-optimization
             Target|                            |x86_64-*-*

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I can't reproduce - there's nothing unusual in your full build log. 
Martin, I think he's testing one of the snapshot tarballs which have names
after the date published.

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #7 from Chris Clayton <chris2553 at googlemail dot com> ---
Yes, Richard's correct. I'm building from snapshot releases. That's why I used
the term "snapshot releases" in comment 4.
I've cloned git://gcc.gnu.org/git/gcc.git and am bisecting between
b642fca1c31b2e2175e0860daf32b4ee0d918085 (11-20201108) and
c746fc40f4ec8cfc1092efd49d567751858d2099 (11-20201115). I'm not 100% sure this
is correct because I'm anything but a git expert and I've never come across a
tree that didn't have branches for different strands of development (e.g gcc-10
gcc-11). git bisect start... reported that there were only 7 commits and that
feels right, so I'll blunder on until someone tells me I'm doing this wrong
(an, hopefully, how I should be doing it)

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #8 from Chris Clayton <chris2553 at googlemail dot com> ---
Sorry, my last comment contains an error. git bisect start... reported 7
bisections would be needed not that there were only 7 commits.

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, so the question is: does it reproduce with the current master or now?

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's only two relevant changes, both before the snapshot tested:
ec383f0bdb4077b744d493d02afff5f13f33029e and
d87ee7f1c9cd2ffa6302cdfd0686d72e5bb7463b

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #11 from Chris Clayton <chris2553 at googlemail dot com> ---
I've finished the bisect and landed at:

[chris:~/scratch/gcc-ICE/gcc]$ git bisect good
bd87cc14ebdb6789e067fb1828d5808407c308b3 is the first bad commit
commit bd87cc14ebdb6789e067fb1828d5808407c308b3
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Nov 11 11:51:59 2020 +0100

    tree-optimization/97623 - Avoid PRE hoist insertion iteration

    The recent previous change in this area limited hoist insertion
    iteration via a param but the following is IMHO better since
    we are not really interested in PRE opportunities exposed by
    hoisting but only the other way around.  So this moves hoist
    insertion after PRE iteration finished and removes hoist
    insertion iteration alltogether.

    2020-11-11  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/97623
            * params.opt (-param=max-pre-hoist-insert-iterations): Remove
            again.
            * doc/invoke.texi (max-pre-hoist-insert-iterations): Likewise.
            * tree-ssa-pre.c (insert): Move hoist insertion after PRE
            insertion iteration and do not iterate it.

            * gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust.
            * gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise.
            * gcc.dg/tree-ssa/ssa-pre-30.c: Likewise.

 gcc/doc/invoke.texi                         |  5 -----
 gcc/params.opt                              |  4 ----
 gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-3.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-7.c |  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-30.c  |  2 +-
 gcc/tree-ssa-pre.c                          | 34 +++++++++++++++++++----------
 6 files changed, 26 insertions(+), 25 deletions(-)

I've also confirmed the outcome. A build with this commit at HEAD fails with
the ICE. A build with the commits parent at HEAD succeeds.

I'll attach the bisect log in a few minutes.

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #12 from Chris Clayton <chris2553 at googlemail dot com> ---
Created attachment 49622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49622&action=edit
git bisect log

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #13 from Chris Clayton <chris2553 at googlemail dot com> ---
(In reply to Martin Liška from comment #9)
> Ok, so the question is: does it reproduce with the current master or now?

Short answer: Yes, it does.

A build done this morning (after pulling the latest changes into the tree I
cloned yesterday) fails with the same ICE error messages.

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
Thank you Chris, I can really confirm that. Working on that..

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |marxin at gcc dot gnu.org

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 49624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49624&action=edit
debugging patch

All right it will be for Richi. I suspect it's a do_hoist_insertion.

reduced test-case:

$ cat /tmp/bid.i
int __bid_ten2k64_res_0, __bid_ten2k64_ind;
void __bid_round64_2_18();

void __bid_ten2k64() {
  for (; __bid_ten2k64_ind <= 9; __bid_ten2k64_ind++)
    if (__bid_ten2k64_res_0)
      break;
  if (__bid_ten2k64_ind)
    __bid_round64_2_18();
}

Steps to reproduce:
1) git co bd87cc14ebdb6789e067fb1828d5808407c308b3
2) patch -p1 < debug.patch
3) mkdir objdir
4) cd objdir
5) ../configure --disable-checking --disable-werror
--enable-languages=c,c++,fortran --disable-multilib
6) make -j16 (you can also use make -j16 'STAGE1_CFLAGS=-g -O2')

... then it build stage2 compiler and crashes in somewhere in libgcc (using the
compiler)

$ ./gcc/xgcc -Bgcc /tmp/bid.i -O2 -c -fverbose-asm
__bid_ten2k64_ind.2_11 = PHI <_3(13), __bid_ten2k64_ind.2_12(4)>
use->stmt: 0x7ffff7548400, use->stmt->code: 18
_3 = __bid_ten2k64_ind.2_11 + 1;
cand->incremented_at: 0x7ffff7544000, cand->incremented_at->code: 6
during GIMPLE pass: ivopts
/tmp/bid.i: In function ‘__bid_ten2k64’:
/tmp/bid.i:4:6: internal compiler error: XXXXXX, code==18

    4 | void __bid_ten2k64() {
      |      ^~~~~~~~~~~~~
0x7ffff7695151 __libc_start_main
        ../csu/libc-start.c:314
0x5ffafd ???
        ../sysdeps/x86_64/start.S:120
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

as seen rewrite_use_nonlinear_expr is miscompiled where code == 18 is
GIMPLE_PHI which is handled in the switch

You can do:

$ cd gcc
$ /home/marxin/Programming/gcc2/objdir/./prev-gcc/xg++
-B/home/marxin/Programming/gcc2/objdir/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/marxin/Programming/gcc2/libstdc++-v3/libsupc++
-L/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fno-checking -gtoggle  -DIN_GCC     -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o tree-ssa-loop-ivopts.o -MT
tree-ssa-loop-ivopts.o -MMD -MP -MF ./.deps/tree-ssa-loop-ivopts.TPo
../../gcc/tree-ssa-loop-ivopts.c -fdbg-cnt=hoisting:932-933 && m && ./xgcc -B.
-O2 -c /tmp/bid.i -fverbose-asm

as seen is first bad debug counter value: -fdbg-cnt=hoisting:932-933, good one
is:
-fdbg-cnt=hoisting:932-932

or you can find your value with

dbgcnt-bisect.py '/home/marxin/Programming/gcc2/objdir/./prev-gcc/xg++
-B/home/marxin/Programming/gcc2/objdir/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/marxin/Programming/gcc2/libstdc++-v3/libsupc++
-L/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/marxin/Programming/gcc2/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c   -g -O2 -fno-checking -gtoggle  -DIN_GCC     -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o tree-ssa-loop-ivopts.o -MT
tree-ssa-loop-ivopts.o -MMD -MP -MF ./.deps/tree-ssa-loop-ivopts.TPo
../../gcc/tree-ssa-loop-ivopts.c' 'make -j16 && ./xgcc -B. -O2 -c /tmp/bid.i'
hoisting 2000

The script is from:
https://github.com/marxin/script-misc

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
Then you will see the following diff in optimized dump:

--- good        2020-11-25 16:27:16.795544128 +0100
+++ bad 2020-11-25 16:26:59.723620747 +0100
@@ -17022,7 +17022,6 @@

 ;; Function rewrite_use_nonlinear_expr
(_ZL26rewrite_use_nonlinear_exprP11ivopts_dataP6iv_useP7iv_cand,
funcdef_no=3488, decl_uid=138891, cgraph_uid=2628, symbol_order=2806)

-Removing basic block 55
 Removing basic block 56
 Removing basic block 57
 Removing basic block 58
@@ -17049,6 +17048,10 @@
 Removing basic block 79
 Removing basic block 80
 Removing basic block 81
+Removing basic block 82
+Removing basic block 83
+Removing basic block 84
+Removing basic block 85
 __attribute__((noipa, noinline, noclone, no_icf))
 rewrite_use_nonlinear_expr (struct ivopts_data * data, struct iv_use * use,
struct iv_cand * cand)
 {
@@ -17182,6 +17185,9 @@
   struct gimple * pretmp_236;
   unsigned char _237;
   struct gimple * _239;
+  unsigned char _265;
+  struct gimple * prephitmp_268;
+  unsigned char _269;
   struct gimple * prephitmp_270;
   struct gimple * pretmp_272;
   struct gimple * _287;
@@ -17252,7 +17258,7 @@
   if (_11 == _12)
     goto <bb 11>; [30.00%]
   else
-    goto <bb 28>; [70.00%]
+    goto <bb 55>; [70.00%]

   <bb 11> [local count: 109521665]:
   _118 = MEM[(const struct gassign *)_12].D.92331.op[0];
@@ -17364,19 +17370,19 @@
   <bb 27> [local count: 583887]:
   pretmp_236 = use_88(D)->stmt;

-  <bb 28> [local count: 972093934]:
-  # prephitmp_15 = PHI <pretmp_228(9), _12(10), pretmp_199(25),
pretmp_236(27), pretmp_19(23)>
+  <bb 28> [local count: 716543374]:
+  # prephitmp_15 = PHI <pretmp_228(9), pretmp_19(23), pretmp_199(25),
pretmp_236(27)>
   _184 = MEM[(const struct gimple *)prephitmp_15].code;
   if (_184 == 6)
-    goto <bb 36>; [44.98%]
+    goto <bb 36>; [25.49%]
   else
-    goto <bb 29>; [55.02%]
+    goto <bb 29>; [74.51%]

-  <bb 29> [local count: 972093934]:
+  <bb 29> [local count: 971122338]:
   if (_184 == 18)
-    goto <bb 30>; [99.90%]
+    goto <bb 30>; [100.00%]
   else
-    goto <bb 38>; [0.10%]
+    goto <bb 38>; [0.00%]

   <bb 30> [local count: 534347641]:
   _190 = MEM[(union tree_node * *)prephitmp_15 + 48B];
@@ -17431,17 +17437,19 @@
   goto <bb 39>; [100.00%]

   <bb 36> [local count: 437211681]:
-  pretmp_211 = MEM[(const struct gassign *)prephitmp_15].D.92331.op[0];
+  # prephitmp_268 = PHI <prephitmp_15(28), _12(55)>
+  pretmp_211 = MEM[(const struct gassign *)prephitmp_268].D.92331.op[0];

   <bb 37> [local count: 534347641]:
-  # _287 = PHI <prephitmp_15(36), _12(13), _12(15), _12(19), _12(20)>
+  # _287 = PHI <prephitmp_268(36), _12(13), _12(15), _12(19), _12(20)>
   # prephitmp_212 = PHI <pretmp_211(36), _118(13), _118(15), _118(19),
_118(20)>
   bsi = gsi_for_stmt (_287);
   pretmp_272 = use_88(D)->stmt;
   goto <bb 39>; [100.00%]

   <bb 38> [local count: 534606]:
-  retval.1249_113 = (int) _184;
+  # _265 = PHI <_184(29), _269(55)>
+  retval.1249_113 = (int) _265;
   internal_error ("XXXXXX, code==%d\n", retval.1249_113);

   <bb 39> [local count: 887017088]:
@@ -17607,6 +17615,13 @@
   _18 ={v} MEM[(struct gimple * *)0B];
   __builtin_trap ();

+  <bb 55> [local count: 255550560]:
+  _269 = MEM[(const struct gimple *)_12].code;
+  if (_269 == 6)
+    goto <bb 36>; [99.62%]
+  else
+    goto <bb 38>; [0.38%]
+
 }

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is a bogus jump threading done in VRP2 caused by bogus range info on
the hoisted gimple_code (use->stmt).

tree-ssa-loop-ivopts.c.137t.pre-  # PT = nonlocal escaped null 
tree-ssa-loop-ivopts.c.137t.pre-  pretmp_252 = use_79(D)->stmt;
tree-ssa-loop-ivopts.c.137t.pre:  pretmp_31 = MEM[(const struct gimple
*)pretmp_252].code;
tree-ssa-loop-ivopts.c.137t.pre-  if (_1 == 4)

the if is the cand->pos == IP_ORIGINAL check.  Now after dom3
suddenly we have

tree-ssa-loop-ivopts.c.188t.dom3-  # PT = nonlocal escaped null 
tree-ssa-loop-ivopts.c.188t.dom3-  pretmp_252 = use_79(D)->stmt;
tree-ssa-loop-ivopts.c.188t.dom3-  # RANGE [6, 6] NONZERO 6
tree-ssa-loop-ivopts.c.188t.dom3:  pretmp_31 = MEM[(const struct gimple
*)pretmp_252].code;
tree-ssa-loop-ivopts.c.188t.dom3-  if (_1 == 4)

before DOM the check is below

  <bb 26> [local count: 972093932]:
  # PT = nonlocal escaped null
  # prephitmp_179 = PHI <pretmp_252(5), pretmp_252(6), pretmp_250(23),
pretmp_216(25), pretmp_210(21)>
  _164 = MEM[(const struct gimple *)prephitmp_179].code;
  # DEBUG g => NULL
  if (_164 == 6)
    goto <bb 34>; [26.31%]

where DOM seems to CSE the load with the earlier (correct) but then
even though it pops the recorded range on pretmp_31 it never backs out
the SSA_NAME_RANGE_INFO?  It's set here:

#0  set_range_info_raw (name=<ssa_name 0x7fffefc9cd38 31>, range_type=VR_RANGE,
min=..., max=...)
    at /home/rguenther/src/trunk/gcc/tree-ssanames.c:359
#1  0x0000000001b1d0f8 in set_range_info (name=<ssa_name 0x7fffefc9cd38 31>,
range_type=VR_RANGE, min=..., max=...)
    at /home/rguenther/src/trunk/gcc/tree-ssanames.c:405
#2  0x00000000027a4d91 in evrp_range_analyzer::set_ssa_range_info
(this=0x7fffffffd100, lhs=<ssa_name 0x7fffefc9cd38 31>, 
    vr=0x444dcd0) at
/home/rguenther/src/trunk/gcc/gimple-ssa-evrp-analyze.c:113
#3  0x00000000027a5597 in evrp_range_analyzer::record_ranges_from_incoming_edge
(this=0x7fffffffd100, 
    bb=<basic_block 0x7fffefca7208 (8)>) at
/home/rguenther/src/trunk/gcc/gimple-ssa-evrp-analyze.c:223
#4  0x00000000027a4ad5 in evrp_range_analyzer::enter (this=0x7fffffffd100,
bb=<basic_block 0x7fffefca7208 (8)>)
    at /home/rguenther/src/trunk/gcc/gimple-ssa-evrp-analyze.c:75
#5  0x00000000019643fb in dom_opt_dom_walker::before_dom_children
(this=0x7fffffffd0d0, bb=<basic_block 0x7fffefca7208 (8)>)
    at /home/rguenther/src/trunk/gcc/tree-ssa-dom.c:1420
#6  0x0000000002736350 in dom_walker::walk (this=0x7fffffffd0d0,
bb=<basic_block 0x7fffefca7208 (8)>)
    at /home/rguenther/src/trunk/gcc/domwalk.c:309
#7  0x0000000001962a54 in (anonymous namespace)::pass_dominator::execute
(this=0x3f2d540, fun=0x7ffff112fb80)
    at /home/rguenther/src/trunk/gcc/tree-ssa-dom.c:724

so we have m_update_global_ranges set here.

218                   push_value_range (vrs[i].first, vrs[i].second);
219                   if (is_fallthru
220                       && m_update_global_ranges
221                       && all_uses_feed_or_dominated_by_stmt (vrs[i].first,
stmt))
222                     {
223                       set_ssa_range_info (vrs[i].first, vrs[i].second);
224                       maybe_set_nonzero_bits (pred_e, vrs[i].first);

but obviously this all_uses_feed_or_dominated_by_stmt doesn't tell us the
whole story:

(gdb) p debug_immediate_uses_for($12)
pretmp_31 : --> single use.
if (pretmp_31 != 6)

in the IL we have not yet updated

  _164 = MEM[(const struct gimple *)prephitmp_179].code;
  # DEBUG g => NULL
  if (_164 == 6)
    goto <bb 34>; [26.31%]
  else
    goto <bb 27>; [73.69%]

to reflect the CSE of this load to pretmp_31!


So we have basically

  _1 = *p;
  if (...)
    {
      if (_1 != 6)
        gcc_unreachable ();  // from the assert
    }
  _2 = *p;
  if (_2 != 6)
    ...

and DOM happily records [6, 6] on _1 based on its single-use and after
that DOM itself CSEs the load and optimizes the second test.

I think all_uses_feed_or_dominated_by_stmt cannot work on its own.
IIRC we have another duplicate of this somewhere.
We have to make sure that the definition is post-dominated by the
condition as well.

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
int __attribute__((noipa))
foo (int flag, int *p)
{
  int val = *p;
  if (flag)
    {
      if (val != 1)
        __builtin_unreachable ();
      return 0;
    }
  int val2 = *p;
  return val2 == 2;
}

int main()
{
  int i = 2;
  if (foo (0, &i) != 1)
    __builtin_abort ();
  return 0;
}


fails with -fno-tree-fre.

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
What a nice reduced test-case.
Btw. started to fail with r8-4962-g4aa458f2ac11aef0 with -O2 -fno-tree-free

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|marxin at gcc dot gnu.org          |unassigned at gcc dot gnu.org

[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

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

commit r11-5443-gc76b3f9e83353a4cd437ca137c1fb835c9b5c21f
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Nov 26 16:13:08 2020 +0100

    tree-optimization/97953 - fix bougs range recorded by EVRP

    EVRP records some ranges from asserts into SSA_NAME_RANGE_INFO
    but fails to assert that the condition the range is derived from
    is always true after the SSA names definition.  The patch implements
    the simplest post-dominance check, basic-block equality.

    2020-11-26  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/97953
            * gimple-ssa-evrp-analyze.c
            (evrp_range_analyzer::record_ranges_from_incoming_edge): Make
            sure the condition post-dominates the SSA definition before
            recording into SSA_NAME_RANGE_INFO.

            * gcc.dg/pr97953.c: New testcase.

[Bug tree-optimization/97953] [8/9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |11.0
           Priority|P3                          |P2
   Target Milestone|---                         |8.5
           Keywords|                            |wrong-code
            Summary|ICE (segfault) during       |[8/9/10 Regression] ICE
                   |GIMPLE pass: loopdone       |(segfault) during GIMPLE
                   |compiling                   |pass: loopdone compiling
                   |libgcc/config/libbid/bid128 |libgcc/config/libbid/bid128
                   |_fma.c:190:1                |_fma.c:190:1

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk, still broken on branches.  Note the hoisting re-ordering made
us no longer discover the full redundancy in PRE itself (as written in the
originating PR we would need to iterate and PRE insertion discovering full
redundancies is a bit of a corner case as well).

[Bug tree-optimization/97953] [8/9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[chris2553 at googlemail dot com]

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

--- Comment #22 from Chris Clayton <chris2553 at googlemail dot com> ---
I've applied Richard's patch to the 20201122 snapshot and can happily report
that the build now completes successfully. My thanks to Martin and Richard.

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at constexpr dot org

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 103986 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

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

commit r10-10391-gd4e5ca668498a41af6417721be2ec69b2eac062e
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Nov 26 16:13:08 2020 +0100

    tree-optimization/97953 - fix bougs range recorded by EVRP

    EVRP records some ranges from asserts into SSA_NAME_RANGE_INFO
    but fails to assert that the condition the range is derived from
    is always true after the SSA names definition.  The patch implements
    the simplest post-dominance check, basic-block equality.

    2020-11-26  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/97953
            * gimple-ssa-evrp-analyze.c
            (evrp_range_analyzer::record_ranges_from_incoming_edge): Make
            sure the condition post-dominates the SSA definition before
            recording into SSA_NAME_RANGE_INFO.

            * gcc.dg/pr97953.c: New testcase.

    (cherry picked from commit c76b3f9e83353a4cd437ca137c1fb835c9b5c21f)

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

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

commit r9-9908-gc018cf9d12c5909a852c33a200cf816204c219b3
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Nov 26 16:13:08 2020 +0100

    tree-optimization/97953 - fix bougs range recorded by EVRP

    EVRP records some ranges from asserts into SSA_NAME_RANGE_INFO
    but fails to assert that the condition the range is derived from
    is always true after the SSA names definition.  The patch implements
    the simplest post-dominance check, basic-block equality.

    2020-11-26  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/97953
            * gimple-ssa-evrp-analyze.c
            (evrp_range_analyzer::record_ranges_from_incoming_edge): Make
            sure the condition post-dominates the SSA definition before
            recording into SSA_NAME_RANGE_INFO.

            * gcc.dg/pr97953.c: New testcase.

    (cherry picked from commit c76b3f9e83353a4cd437ca137c1fb835c9b5c21f)

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|                            |10.3.0, 9.4.0
      Known to work|                            |10.3.1, 9.4.1
         Resolution|---                         |FIXED

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[daniel at constexpr dot org]

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

--- Comment #29 from Daniel Scharrer <daniel at constexpr dot org> ---
Hi, shouldn't this be

 Known to fail  10.3.**1**
 Known to work  10.3.**2**

[Bug tree-optimization/97953] [9/10 Regression] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1

[pinskia at gcc dot gnu.org]

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

--- Comment #30 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Daniel Scharrer from comment #29)
> Hi, shouldn't this be
> 
>  Known to fail  10.3.**1**
>  Known to work  10.3.**2**

No, 10.3.1 means the development branch that the 10.4.0 release will come. See
https://gcc.gnu.org/develop.html#num_scheme for more details on that:
To summarize, the first release of GCC 5 will be GCC 5.1.0 while development
snapshots will be GCC 5.0.0 and snapshots from the release branch GCC 5.n.1.

Basically x.y.1 is just a snapshot from the release branch and never a release
itself.