[Bug bootstrap/99920] New: [10 regression] ICE building gcc 10 on power 7 BE

[Bug bootstrap/99920] New: [10 regression] ICE building gcc 10 on power 7 BE

[seurer at gcc dot gnu.org]

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

            Bug ID: 99920
           Summary: [10 regression] ICE building gcc 10 on power 7 BE
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:6aa75d3740c309aeead9c430a6779f4a347f4403, r10-9659

This occurs at this commit but it is not the source of it (I am still looking).

Configure used:  /home/seurer/gcc/git/gcc-10-test/configure
--enable-languages=c,fortran,c++ --with-cpu=power7 --enable-bootstrap
--enable-multilib

A whole bunch of ICEs like the following occur when building gcc on power 7 BE.
 It does not occurs on power 8 BE.

/home/seurer/gcc/git/build/gcc-10-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-10-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-10-test/powerpc64-unknown-linux-gnu/sys-include
  -fno-checking -g -O2 -m32 -O2  -g -O2 -DIN_GCC    -W -Wall -Wwrite-strings
-Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -fPIC -mlong-double-128
-mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC
-mlong-double-128 -mno-minimal-toc -I. -I. -I../../.././gcc
-I/home/seurer/gcc/git/gcc-10-test/libgcc
-I/home/seurer/gcc/git/gcc-10-test/libgcc/.
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../gcc
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../include
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/dpd
-I/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber -DHAVE_CC_TLS  -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
during GIMPLE pass: store-merging
In file included from /home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:56:
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c: In function '__muldi3':
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.h:219:20: internal compiler
error: Segmentation fault
  219 | #define __NDW(a,b) __ ## a ## di ## b
      |                    ^~
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.h:273:18: note: in expansion of
macro '__NDW'
  273 | #define __muldi3 __NDW(mul,3)
      |                  ^~~~~
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:548:1: note: in expansion of
macro '__muldi3'
  548 | __muldi3 (DWtype u, DWtype v)
      | ^~~~~~~~
0x111d588f crash_signal
        /home/seurer/gcc/git/gcc-10-test/gcc/toplev.c:328
0x125d1930 trim_filename(char const*)
        /home/seurer/gcc/git/gcc-10-test/gcc/diagnostic.c:1223
0x125d4273 fancy_abort(char const*, int, char const*)
        /home/seurer/gcc/git/gcc-10-test/gcc/diagnostic.c:1778
0x10a76dab operand_compare::hash_operand(tree_node const*, inchash::hash&,
unsigned int)
        /home/seurer/gcc/git/gcc-10-test/gcc/fold-const.c:3768
0x10a7766b inchash::add_expr(tree_node const*, inchash::hash&, unsigned int)
        /home/seurer/gcc/git/gcc-10-test/gcc/fold-const.c:3919
0x1122c2af iterative_hash_expr
        /home/seurer/gcc/git/gcc-10-test/gcc/tree.h:5207
0x11232c77 tree_operand_hash::hash(tree_node* const&)
        /home/seurer/gcc/git/gcc-10-test/gcc/tree-hash-traits.h:34
0x1231a2af hash
        /home/seurer/gcc/git/gcc-10-test/gcc/hash-map-traits.h:50
0x1231b97b get
        /home/seurer/gcc/git/gcc-10-test/gcc/hash-map.h:184
0x1232fbaf process_store
        /home/seurer/gcc/git/gcc-10-test/gcc/gimple-ssa-store-merging.c:4883
0x123304a7 execute
        /home/seurer/gcc/git/gcc-10-test/gcc/gimple-ssa-store-merging.c:5040

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |10.3
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Could you please attach preprocessed source so that I can try to look at it
quickly with a cross-compiler?  Thanks.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't reproduce btw, ../configure --enable-languages=c,fortran,c++
--with-cpu=power7 --enable-bootstrap --enable-multilib
on gcc110.fsffrance.org built just fine.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

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

--- Comment #3 from seurer at gcc dot gnu.org ---
I changed to use gcc 8.4 as my build compiler and the ICEs went away.  I assume
it was an issue with the older build compiler I had been using.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 6 Apr 2021, seurer at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99920
> 
> seurer at gcc dot gnu.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |RESOLVED
>          Resolution|---                         |INVALID
> 
> --- Comment #3 from seurer at gcc dot gnu.org ---
> I changed to use gcc 8.4 as my build compiler and the ICEs went away.  I assume
> it was an issue with the older build compiler I had been using.

Possibly - what version was that?

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10 doesn't require C++11 and so in theory everything from GCC 4.1 till GCC
11 should be supported as system compiler, perhaps we need some workaround for
some known bugs somewhere (we have a couple of them already).

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-04-06
         Resolution|INVALID                     |---
             Status|RESOLVED                    |REOPENED
     Ever confirmed|0                           |1

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If the problematic older system gcc was 4.1+, can you please bisect among *.o
files compiled by the system gcc?
If the ICE is with the stage1 gcc when building stage1 libgcc, then
the suspected TUs could be gimple-ssa-store-merging.o or fold-const.o, would be
nice to start with those.
I.e. build again with your older system gcc, verify it fails, make a copy of
those two *.o files, rebuild them with gcc 8.x, make cc1 cc1plus and verify it
doesn't ICE anymore.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[seurer at gcc dot gnu.org]

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

--- Comment #7 from seurer at gcc dot gnu.org ---
I will try to recreate but I got rid of the old build compiler.  It was a
leftover from some work many years ago and I had forgotten I was even using it.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
It is during stage1 and I was able to recreate using the system distro
compiler, gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux).  I
will bisect on the .o's now.

FWIW here is a list of the ones that failed (not necessarily the entire list):

/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:2155:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decLibrary.c:41:1:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1534:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1385:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:271:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:147:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1576:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:109:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:187:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:160:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:84:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decContext.c:227:18:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1590:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:122:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1460:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1395:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:212:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:232:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:2030:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decPacked.c:229:3:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/dfp-bit.c:96:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:2089:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decCommon.c:242:19:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/dpd/decimal64.c:429:3:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decLibrary.c:41:1:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:232:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:271:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1395:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:212:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:147:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:122:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1534:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:109:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1576:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:160:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:84:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1590:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:187:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:2155:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1385:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/dfp-bit.c:96:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decBasic.c:3622:12:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:1460:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:2089:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/libgcc2.c:2030:1: internal compiler
error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decContext.c:227:18:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decPacked.c:229:3:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decCommon.c:242:19:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/dpd/decimal64.c:429:3:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decBasic.c:3622:12:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decBasic.c:3622:12:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decNumber.c:3760:3:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decBasic.c:718:13:
internal compiler error: Segmentation fault
/home/seurer/gcc/git/gcc-10-test/libgcc/../libdecnumber/decNumber.c:3760:3:
internal compiler error: Segmentation fault

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Built r152973 ../configure --disable-bootstrap --enable-languages=c,c++ ,
installed and built gcc trunk with that as system compiler and can't reproduce
it.  Maybe some SUSE patches or the SUSE compiler was configured a different
way...

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 7 Apr 2021, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99920
> 
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Built r152973 ../configure --disable-bootstrap --enable-languages=c,c++ ,
> installed and built gcc trunk with that as system compiler and can't reproduce
> it.  Maybe some SUSE patches or the SUSE compiler was configured a different
> way...

This is the SLES11 system compiler (the last BE SLES).  It's configured
with --with-cpu=power4 --enable-secureplt --with-long-double-128.  We
do have a patch with power7 enablement (but just recognizing the
command-line option, nothing else).  And yes, lots of more cobbled
up patches (and we never updated to a 4.3.6 baseline either).

That said, it's a bit too short notice to start digging into this
myself and honestly if FSF 4.3.4 and 4.3.6 are not affected I'd not
worry (and instead I'll see to fixing SLE11 instead if the need
arises).  SLE11 also has access to GCC 4.8.5 btw. (just with
binaries inconveniently named gcc-4.8).

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[seurer at gcc dot gnu.org]

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

--- Comment #11 from seurer at gcc dot gnu.org ---
Swapping out those two .o files (individually and together) didn't yield a
successful build.  I brought in the 8.4.0 .o files in one at a time and
eventually I got a successful build but at that point it had brought in most of
them.  I am now trying each .o swapped in individually.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Usually I'm trying to do binary search in these cases, build one tree with the
bad compiler, one with good one, cp -al one of the trees to a new dir, make a
list of the object files, start with half/half, copy them and touch all, make
cc1 cc1plus, test the libgcc compilation, etc.  That works if there is a single
miscompiled one.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
So I can confirm the issue trying to build gcc10 packages for SLE11 ppc64
(after much massaging).  It works fine (past the failure point) on x86_64
with the same versioned host compiler.  It works fine when using gcc 4.8
as host compiler (also available on SLES11).

With the 4.3 based host compiler I see loads of

[  309s] In file included from ../../gcc/gimple-ssa-store-merging.c:168:
[  309s] ../../gcc/rtl.h: In function 'rtx_def* rtx_init(rtx_def*, rtx_code)':
[  309s] ../../gcc/rtl.h:2966: warning: invalid access to non-static data
member 'rtx_def::u' of NULL object
[  309s] ../../gcc/rtl.h:2966: warning: (perhaps the 'offsetof' macro was used
incorrectly)

also

[  625s] ../../gcc/cp/parser.c:31339:   instantiated from here
[  625s] ../../gcc/vec.h:1285: warning: invalid access to non-static data
member
 'vec<class_decl_loc_t::class_key_loc_t, va_heap, vl_embed>::m_vecdata' of NULL 
object
[  625s] ../../gcc/vec.h:1285: warning: (perhaps the 'offsetof' macro was used
incorrectly)
[  625s] ../../gcc/vec.h: In static member function 'static size_t vec<T, A,
vl_embed>::embedded_size(unsigned int) [with T = cp_expr, A = va_heap]':


when I bootstrap with STAGE1_CFLAGS="-O2 -g" then it gets past the failure
point as well (this does hint at some C++ initialization issue, IIRC those
plagued us a lot).  Note we're using STAGE1_CFLAGS="-O2 -g" for our
package builds (because we use known-good host compilers and to speed up
builds...) so we wouldn't have noticed this issue.

I'm still confident the error lies with our patched GCC 4.3.3 but I'm not
too interested in tracking the issue down ...

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #13)
> So I can confirm the issue trying to build gcc10 packages for SLE11 ppc64
> (after much massaging).  It works fine (past the failure point) on x86_64
> with the same versioned host compiler.  It works fine when using gcc 4.8
> as host compiler (also available on SLES11).
> 
> With the 4.3 based host compiler I see loads of
> 
> [  309s] In file included from ../../gcc/gimple-ssa-store-merging.c:168:
> [  309s] ../../gcc/rtl.h: In function 'rtx_def* rtx_init(rtx_def*,
> rtx_code)':
> [  309s] ../../gcc/rtl.h:2966: warning: invalid access to non-static data
> member 'rtx_def::u' of NULL object
> [  309s] ../../gcc/rtl.h:2966: warning: (perhaps the 'offsetof' macro was
> used incorrectly)

the same warning happens with -save-temps and the .ii file has

# 2956 "../../gcc/rtl.h"
extern long trunc_int_for_mode (long, machine_mode);
extern poly_int64 trunc_int_for_mode (poly_int64, machine_mode);
extern rtx plus_constant (machine_mode, rtx, poly_int64, bool = false);
extern long get_stack_check_protect (void);


extern rtx rtx_alloc (enum rtx_code );
inline rtx
rtx_init (rtx rt, enum rtx_code code)
{
  memset (rt, 0, __builtin_offsetof (struct rtx_def, u));
  ((rt)->code = (code));
  return rt;
}


a build / gdb inside qemu (ick) shows

Program received signal SIGSEGV, Segmentation fault.
0x000000001218ecb4 in trim_filename (
    name=0x1293bbf0 <vtable for (anonymous
namespace)::pass_early_thread_jumps+16> "") at ../../gcc/diagnostic.c:1223
1223      while (q[0] == '.' && q[1] == '.' && IS_DIR_SEPARATOR (q[2]))
(gdb) bt
#0  0x000000001218ecb4 in trim_filename (
    name=0x1293bbf0 <vtable for (anonymous
namespace)::pass_early_thread_jumps+16> "") at ../../gcc/diagnostic.c:1223
#1  0x0000000012191cf0 in fancy_abort (
    file=0x1293bbf0 <vtable for (anonymous
namespace)::pass_early_thread_jumps+16> "", line=3768, function=0x12bce0c8
<cfun> "") at ../../gcc/diagnostic.c:1778
#2  0x0000000010943ac4 in operand_compare::hash_operand (
    this=0x12c87ba8 <global_options>, t=0x1ffffde22800, hstate=..., flags=0)
    at ../../gcc/fold-const.c:3768
#3  0x0000000010944104 in inchash::add_expr (t=0x1ffffde22800, hstate=..., 
    flags=0) at ../../gcc/fold-const.c:3919
#4  0x000000001102a2ec in iterative_hash_expr (tree=0x1ffffde22800, seed=0)
    at ../../gcc/tree.h:5207
#5  0x0000000011030e18 in tree_operand_hash::hash (
    t=@0x3fffffffe220: 0x1ffffde22800) at ../../gcc/tree-hash-traits.h:34
#6  0x0000000011f71eb8 in
simple_hashmap_traits<default_hash_traits<tree_operand_hash>,
<unnamed>::imm_store_chain_info*>::hash(tree_node * const&) (
    h=@0x3fffffffe220: 0x1ffffde22800) at ../../gcc/hash-map-traits.h:50
#7  0x0000000011f73378 in hash_map<tree_operand_hash,
<unnamed>::imm_store_chain_info*,
simple_hashmap_traits<default_hash_traits<tree_operand_hash>,
<unnamed>::imm_store_chain_info*> >::get(tree_node * const&) (this=0x12cec998, 
    k=@0x3fffffffe220: 0x1ffffde22800) at ../../gcc/hash-map.h:184
#8  0x0000000011f846f4 in (anonymous
namespace)::pass_store_merging::process_sto---Type <return> to continue, or q
<return> to quit---
re (this=0x12cec940, stmt=0x1ffffdd61e50)
    at ../../gcc/gimple-ssa-store-merging.c:4883
#9  0x0000000011f84fec in (anonymous namespace)::pass_store_merging::execute (
    this=0x12cec940, fun=0x1ffffdd90000)
    at ../../gcc/gimple-ssa-store-merging.c:5040
#10 0x0000000010df8740 in execute_one_pass (pass=0x12cec940)
    at ../../gcc/passes.c:2502
#3  0x0000000010944104 in inchash::add_expr (t=0x1ffffde22800, hstate=..., 
    flags=0) at ../../gcc/fold-const.c:3919
3919      default_compare_instance.hash_operand (t, hstate, flags);
(gdb) p t
$1 = (const_tree) 0x1ffffde22800
(gdb) p debug_tree (t)
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
 <addr_expr 0x1ffffde22800
    type <pointer_type 0x1ffffdd5bda8
        type <union_type 0x1ffffdd50d20 _FP_UNION_Q sizes-gimplified
asm_written type_0 TI
            size <integer_cst 0x1ffffdab1068 constant 128>
            unit-size <integer_cst 0x1ffffdab1080 constant 16>
            align:128 warn_if_not_align:0 symtab:8191 alias-set 4
canonical-type 0x1ffffdd50d20 fields <field_decl 0x1ffffdae3a30 flt> context
<translation_unit_decl 0x1ffffdd80078 trunckfdf2-sw.c>
            pointer_to_this <pointer_type 0x1ffffdd5bda8> chain <type_decl
0x1ffffdae3998 D.3040>>
        public unsigned DI
        size <integer_cst 0x1ffffdab1020 constant 64>
        unit-size <integer_cst 0x1ffffdab1038 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x1ffffdd5bda8>

    arg:0 <var_decl 0x1ffffff90bd0 _FP_UNPACK_RAW_2_flo type <union_type
0x1ffffdd50d20 _FP_UNION_Q>
        used read TI trunckfdf2-sw.c:46:31 size <integer_cst 0x1ffffdab1068
128> unit-size <integer_cst 0x1ffffdab1080 16>
        align:128 warn_if_not_align:0 context <function_decl 0x1ffffdd2ce00
__trunckfdf2>>>
(gdb) down
#2  0x0000000010943ac4 in operand_compare::hash_operand (
    this=0x12c87ba8 <global_options>, t=0x1ffffde22800, hstate=..., flags=0)
    at ../../gcc/fold-const.c:3768
3768            gcc_assert (flags & OEP_HASH_CHECK);
(gdb) l
3763            hash_operand (TREE_OPERAND (TREE_OPERAND (t, 0), 0),
3764                          hstate, flags);
3765          /* Don't ICE on FE specific trees, or their arguments etc.
3766             during operand_equal_p hash verification.  */
3767          else if (!IS_EXPR_CODE_CLASS (tclass))
3768            gcc_assert (flags & OEP_HASH_CHECK);
(gdb) p tclass
$3 = tcc_exceptional
(gdb) p code
$4 = ADDR_EXPR

eh?  Looks like some unfortunate mis-optimization of
operand_compare::hash_operand ... :/

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Dump of assembler code from 0x1094366c to 0x109436e0:
   0x000000001094366c <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2432>:     lhz     r0,0(r9)
   0x0000000010943670 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2436>:     clrldi  r0,r0,48
   0x0000000010943674 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2440>:     stw     r0,200(r31)
   0x0000000010943678 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2444>:     lwz     r0,200(r31)
=> 0x000000001094367c <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2448>:     clrldi  r0,r0,32
   0x0000000010943680 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2452>:     extsw   r0,r0
   0x0000000010943684 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2456>:     ld      r9,-11776(r2)
   0x0000000010943688 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2460>:     rldicr  r0,r0,2,61
   0x000000001094368c <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2464>:     add     r9,r9,r0
   0x0000000010943690 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2468>:     lwz     r0,0(r9)
   0x0000000010943694 <operand_compare::hash_operand(tree_node const*,
inchash::hash&, unsigned int)+2472>:     stw     r0,152(r31)

r0 is ADDR_EXPR (130)

(gdb) p/x $r2
$21 = 0x12b81a48
(gdb) p/x tree_code_type
$22 = 0x123216a0 <tree_code_type>

after ld      r9,-11776(r2):

(gdb) p/x $r9
$25 = 0x12a9fc38
rldicr  r0,r0,2,61
(gdb) p $r0
$26 = 520
add     r9,r9,r0
(gdb) p/x $r9
$27 = 0x12a9fe40

and then we load 0 (tcc_exceptional) from $r9, but

(gdb) p tree_code_type[130]
$31 = tcc_expression

so sth is obviously broken here, but I don't understand ppc assembly enough
to spot what.  I guess r2 is "off"?  It has this same value at function
entry already.

Are we maybe running into some linker relaxation / TOC overflow issue
(given that -O2 works)?  We're using -mno-minimal-toc when building libgcc
but the host compiler uses plain -g -fno-PIE and we don't supply any
special linker flags for cc1 either.  Note this build uses binutils 2.25.0
(Bill, is that what you use as well?)

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 50528
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50528&action=edit
preprocessed source of fold-const.c

This is the preprocessed source of fold-const.c with the offending function. 
Compiled as

/usr/lib64/gcc/powerpc64-suse-linux/4.3/cc1plus -E -quiet -v -I. -I.
-I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc/../libbacktrace -MMD fold-const.d -MF ./.deps/fold-const.TPo -MP
-MT fold-const.o -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix
-D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -DIN_GCC
-DHAVE_CONFIG_H ../../gcc/fold-const.c -msecure-plt -mno-minimal-toc
-mcpu=power4 -std=gnu++98 -W -Wall -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-PIE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -fworking-directory -fpch-preprocess -o
fold-const.ii

with the host compiler configured like

Target: powerpc64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=release
--with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=power4
--enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux
Thread model: posix
gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) 

(the SVN rev. is off and there are custom patches ontop of that)

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.3                        |10.4

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE

[seurer at gcc dot gnu.org]

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

--- Comment #18 from seurer at gcc dot gnu.org ---
The binutils I use on there is (GNU Binutils) 2.23.52.20130522

[Bug bootstrap/99920] [10 regression] ICE building gcc 10 on power 7 BE with GCC 4.3.4 (SUSE) host compiler

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10 regression] ICE         |[10 regression] ICE
                   |building gcc 10 on power 7  |building gcc 10 on power 7
                   |BE                          |BE with GCC 4.3.4 (SUSE)
                   |                            |host compiler
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
I suppose we should close the bug here and open one on the SUSE side if we/IBM
cares enough to debug the 4.3.4 PPC BE compiler.  Clarifying the summary at
least.  The issue sofar has not been reproduced with a clean FSF tree.

I doubt we're going to work around this issue in the GCC 10 tree so WONTFIX
on the GCC 10 side and of course GCC 4.3 is no longer maintained here.