[Bug bootstrap/95952] New: [8.4.1 regression] gcc-8 bootstrap failure on powerpc64-linux

[Bug bootstrap/95952] New: [8.4.1 regression] gcc-8 bootstrap failure on powerpc64-linux

[mikpelinux at gmail dot com]

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

            Bug ID: 95952
           Summary: [8.4.1 regression] gcc-8 bootstrap failure on
                    powerpc64-linux
           Product: gcc
           Version: 8.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Attempting to bootstrap gcc-8-20200625 on powerpc64-linux-gnu fails with an
ICE:

/mnt/scratch/objdir8/./gcc/xgcc -B/mnt/scratch/objdir8/./gcc/ -xc -nostdinc
/dev/null -S -o /dev/null
-fself-test=/mnt/scratch/gcc-8-20200625/gcc/testsuite/selftests
<built-in>: internal compiler error: in altivec_init_builtins, at
config/rs6000/rs6000.c:18021
0x10d8cd8f altivec_init_builtins
        /mnt/scratch/gcc-8-20200625/gcc/config/rs6000/rs6000.c:18021
0x10d8ae87 rs6000_init_builtins
        /mnt/scratch/gcc-8-20200625/gcc/config/rs6000/rs6000.c:17458
0x100f135b c_define_builtins
        /mnt/scratch/gcc-8-20200625/gcc/c-family/c-common.c:3930
0x100f34d3 c_common_nodes_and_builtins()
        /mnt/scratch/gcc-8-20200625/gcc/c-family/c-common.c:4400
0x1002147b c_init_decl_processing(/mnt/scratch/objdir8/./gcc/xgcc
-B/mnt/scratch/objdir8/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null
-fself-test=/mnt/scratch/gcc-8-20200625/gcc/testsuite/selftests
<built-in>: internal compiler error: in altivec_init_builtins, at
config/rs6000/rs6000.c:18021
0x10d8cd8f altivec_init_builtins
        /mnt/scratch/gcc-8-20200625/gcc/config/rs6000/rs6000.c:18021
0x10d8ae87 rs6000_init_builtins
        /mnt/scratch/gcc-8-20200625/gcc/config/rs6000/rs6000.c:17458
0x100f135b c_define_builtins
        /mnt/scratch/gcc-8-20200625/gcc/c-family/c-common.c:3930
0x100f34d3 c_common_nodes_and_builtins()
        /mnt/scratch/gcc-8-20200625/gcc/c-family/c-common.c:4400
0x1002147b c_init_decl_processing()
        /mnt/scratch/gcc-8-20200625/gcc/c/c-decl.c:4189
0x10077677 c_objc_common_init()
        /mnt/scratch/gcc-8-20200625/gcc/c/c-objc-common.c:59
0x108ab4ab lang_dependent_init
        /mnt/scratch/gcc-8-20200625/gcc/toplev.c:1892
0x108abdc3 do_compile
        /mnt/scratch/gcc-8-20200625/gcc/toplev.c:2146
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.
make[3]: *** [s-selftest-c] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir8/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir8'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir8'
make: *** [bootstrap] Error 2)
        /mnt/scratch/gcc-8-20200625/gcc/c/c-decl.c:4189
0x10077677 c_objc_common_init()
        /mnt/scratch/gcc-8-20200625/gcc/c/c-objc-common.c:59
0x108ab4ab lang_dependent_init
        /mnt/scratch/gcc-8-20200625/gcc/toplev.c:1892
0x108abdc3 do_compile
        /mnt/scratch/gcc-8-20200625/gcc/toplev.c:2146
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.
make[3]: *** [s-selftest-c] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir8/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir8'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir8'
make: *** [bootstrap] Error 2

The ICE is the following assert failing:

          /* Cannot define builtin if the instruction is disabled.  */
          gcc_assert (d->icode != CODE_FOR_nothing);

Recent snapshots of gcc-9/10/11 all bootstrap fine, as did earlier gcc-8
snapshots.  A bisection identified the following as the culprit:

>From 09f2293fac1785681f8ceaf6ae6d2d5cfe519b08 Mon Sep 17 00:00:00 2001
From: Will Schmidt <will_schmidt@vnet.ibm.com>
Date: Tue, 7 Apr 2020 16:32:39 -0500
Subject: [PATCH] rs6000 pragma fix backport from mainline to gcc-8

Reverting that commit from current head of gcc-8 allows it to bootstrap again.

Configuration parameters:
/mnt/scratch/gcc-8-20200625/configure --prefix=/mnt/scratch/install8
--with-gmp=/home/mikpe/pkgs/linux-ppc64/gmp-6.2.0
--with-mpfr=/home/mikpe/pkgs/linux-ppc64/mpfr-4.0.2
--with-mpc=/home/mikpe/pkgs/linux-ppc64/mpc-1.1.0 --without-isl
--disable-plugin --disable-lto --disable-nls --enable-threads=posix
--with-cpu=default32 --enable-checking=release --disable-libmudflap
--enable-linker-build-id --enable-languages=c,ada,c++

[Bug bootstrap/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8.4.1 regression] gcc-8    |[8 Regression] gcc-8
                   |bootstrap failure on        |bootstrap failure on
                   |powerpc64-linux             |powerpc64-linux
                 CC|                            |wschmidt at gcc dot gnu.org
           Priority|P3                          |P1
   Target Milestone|---                         |8.5

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bill, please have a look.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

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

--- Comment #2 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Ah, this is Will, not me.  Will, can you please look into this ASAP?

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #3 from Will Schmidt <willschm at gcc dot gnu.org> ---
Couldn't duplicate on P8/BE.  I still have a couple builds going to see if I
can duplicate elsewhere.

I see "--with-cpu=default32 " in the config string.  Is this an older hardware
platform?  

thanks

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

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

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Will Schmidt from comment #3)
> Couldn't duplicate on P8/BE.  I still have a couple builds going to see if I
> can duplicate elsewhere.
> 
> I see "--with-cpu=default32 " in the config string.  Is this an older
> hardware platform?  

--with-cpu=default32 is valid on any BE system, old or new.  It just creates a
compiler that defaults to -m32 rather than -m64.  Ie, the compile above that is
ICEing has an implicit -m32 added.  I can help you build a default32 gcc if
just adding -m32 to your compile doesn't ICE on the test case.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #4)
> I can help you build a default32 gcc if just adding -m32 to your
> compile doesn't ICE on the test case.

I should mention, it's not as easy as just configuring with
--with-cpu=default32.  You also need a binutils that has been built as a 32-bit
binary.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[mikpelinux at gmail dot com]

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

--- Comment #6 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Peter Bergner from comment #5)
> (In reply to Peter Bergner from comment #4)
> > I can help you build a default32 gcc if just adding -m32 to your
> > compile doesn't ICE on the test case.
> 
> I should mention, it's not as easy as just configuring with
> --with-cpu=default32.  You also need a binutils that has been built as a
> 32-bit binary.

This is an Apple G5 running a 64-bit linux-5.7 kernel and a mostly 32-bit
user-space, hence the --with-cpu=default32 (which has been there since
"forever").

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

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

--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
I've tried many 32-bit builds, but cannot reproduce the error.  I tried with
top of the releases/gcc-8 branch, using releases/gcc-8 branch at commit
09f2293fac1785681f8ceaf6ae6d2d5cfe519b08 and varying configure options.  That
said, I am using a trunk binutils build from today, because I needed a 32-bit
binutils.  What version of binutils are you using?

--- Comment #8 from Segher Boessenkool <segher at gcc dot gnu.org> ---
So what is the instruction / builtin / anything where it fails?

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[mikpelinux at gmail dot com]

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

--- Comment #9 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Peter Bergner from comment #7)
> I've tried many 32-bit builds, but cannot reproduce the error.  I tried with
> top of the releases/gcc-8 branch, using releases/gcc-8 branch at commit
> 09f2293fac1785681f8ceaf6ae6d2d5cfe519b08 and varying configure options. 
> That said, I am using a trunk binutils build from today, because I needed a
> 32-bit binutils.  What version of binutils are you using?

binutils-2.23.88.0.1-13.fc20.ppc64

I can build a recent binutils release and retry the gcc-8 bootstrap with that
tomorrow.  But since gcc-9/10/11 all bootstrap Ok, I find it difficult to
suspect it's a binutils issue.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #10 from Will Schmidt <willschm at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #8)
> So what is the instruction / builtin / anything where it fails?

I've managed to recreate the altivec_init_builtins ICE issue on a yellowdog
box.  (4-core 970MP).

Looks like it is trying to parse 
__builtin_altivec_vcmpnezb_p
at the time it fails.

Continuing to debug.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Mikael Pettersson from comment #9)
> binutils-2.23.88.0.1-13.fc20.ppc64
> 
> I can build a recent binutils release and retry the gcc-8 bootstrap with
> that tomorrow.  But since gcc-9/10/11 all bootstrap Ok, I find it difficult
> to suspect it's a binutils issue.

At some point in the past, GCC used to disable some instruction patterns
depending on whether the binutils you're building against supports those
instructions or not.  Now, GCC will always generate every instruction you ask
it to, but you might get an assembler error trying to assemble those
instructions.  I think that change was somewhere in the GCC8 or GCC9 timeframe.
 It could be your old binutils in GCC8 is silently turning off some support and
that is causing the problem.  I'll try building a 2.23ish binutils and using
that for my GCC8 build.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[mikpelinux at gmail dot com]

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

--- Comment #12 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Peter Bergner from comment #11)
> At some point in the past, GCC used to disable some instruction patterns
> depending on whether the binutils you're building against supports those
> instructions or not.  Now, GCC will always generate every instruction you
> ask it to, but you might get an assembler error trying to assemble those
> instructions.  I think that change was somewhere in the GCC8 or GCC9
> timeframe.  It could be your old binutils in GCC8 is silently turning off
> some support and that is causing the problem.  I'll try building a 2.23ish
> binutils and using that for my GCC8 build.

OK.  Meanwhile I had a successful bootstrap of GCC8 with binutils-2.34.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #13 from Will Schmidt <willschm at gcc dot gnu.org> ---
Created attachment 48871
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48871&action=edit
proposed patch

Attached patch appears sufficient to resolve the issue on the 970 based box I
have access to.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #14 from Will Schmidt <willschm at gcc dot gnu.org> ---
(In reply to Will Schmidt from comment #13)
> Created attachment 48871 [details]
> proposed patch
> 
> Attached patch appears sufficient to resolve the issue on the 970 based box
> I have access to.

Mikael, would be appreciated if you could give that a run-through to confirm it
fixes the problem on your system.
thanks,

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[mikpelinux at gmail dot com]

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

--- Comment #15 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Will Schmidt from comment #14)
> (In reply to Will Schmidt from comment #13)
> > Created attachment 48871 [details]
> > proposed patch
> > 
> > Attached patch appears sufficient to resolve the issue on the 970 based box
> > I have access to.
> 
> Mikael, would be appreciated if you could give that a run-through to confirm
> it fixes the problem on your system.
> thanks,

I can confirm that this patch restores gcc-8 bootstrap with the older binutils.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #16 from Will Schmidt <willschm at gcc dot gnu.org> ---
(In reply to Mikael Pettersson from comment #15)
> (In reply to Will Schmidt from comment #14)
> > (In reply to Will Schmidt from comment #13)
> > > Created attachment 48871 [details]
> > > proposed patch
> > > 
> > > Attached patch appears sufficient to resolve the issue on the 970 based box
> > > I have access to.
> > 
> > Mikael, would be appreciated if you could give that a run-through to confirm
> > it fixes the problem on your system.
> > thanks,
> 
> I can confirm that this patch restores gcc-8 bootstrap with the older
> binutils.

Thanks :-) 
Patch posted to list for review.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Will Schmidt
<willschm@gcc.gnu.org>:

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

commit r8-10362-geba1113dbdf4b1d0d88755b2538327a1d09837b3
Author: Will Schmidt <will_schmidt@vnet.ibm.com>
Date:   Mon Jul 13 13:38:17 2020 -0500

    [PATCH] rs6000 improve handling of built-in initialization [PR95952]

      Handle a scenario with a combination of old hardware, gcc-8 and
    binutils where gcc will ICE during it's selftest.  This ICE was exposed
    when the builtin processing for better #pragma support was added, where
    we no longer skip builtin initialization based on the current mask.

    Per the bug report and assorted debug, the ICE occurrs when building
    the gcc-8 branch on a 970* based system with an old binutils.  (gcc-9 and
    newer is OK.  binutils 2.34 is reported to allow success).

    The attached patch adds a clause to the builtin initialization to skip
    initialization of a builtin when the builtin mask is set but the icode
    value is zero.   The subsequent assert check remains in place.

    2020-07-13  Will Schmidt  <will_schmidt@vnet.ibm.com>

    gcc/ChangeLog:

            PR target/95952

            * config/rs6000/rs6000.c (altivec_init_builtins): Add continue
clause to
            predicate builtin handling.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

Will Schmidt <willschm at gcc dot gnu.org> changed:

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

--- Comment #18 from Will Schmidt <willschm at gcc dot gnu.org> ---
fix committed, should be done here.   Thanks.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

Will Schmidt <willschm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #19 from Will Schmidt <willschm at gcc dot gnu.org> ---
closed.