[Bug target/95381] New: [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[Bug target/95381] New: [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

            Bug ID: 95381
           Summary: [11 Regression]: Bootstrap on m68k fails with ICE: in
                    operator[], at vec.h:867
           Product: gcc
           Version: 11.0
               URL: https://buildd.debian.org/status/fetch.php?pkg=gcc-sna
                    pshot&arch=m68k&ver=1%3A20200525-1&stamp=1590584234&ra
                    w=0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glaubitz at physik dot fu-berlin.de
                CC: bernds at gcc dot gnu.org, schwab at gcc dot gnu.org
  Target Milestone: ---

Bootstrapping gcc-11 on m68k fails with:

ln -sf libgccjit.so.0 libgccjit.so
echo | /<<PKGBUILDDIR>>/build-jit/./gcc/xgcc
-B/<<PKGBUILDDIR>>/build-jit/./gcc/ -E -dM - | \
  sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
         -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
  sort -u > tmp-macro_list
/bin/bash ../../src/gcc/../move-if-change tmp-macro_list macro_list
echo timestamp > s-macro_list
/<<PKGBUILDDIR>>/build-jit/./gcc/xgcc -B/<<PKGBUILDDIR>>/build-jit/./gcc/ -xc
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../src/gcc/testsuite/selftests
cc1: internal compiler error: in operator[], at vec.h:867
mmap: Bad file descriptor
close: Bad file descriptor
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
/<<PKGBUILDDIR>>/build-jit/./gcc/xgcc -B/<<PKGBUILDDIR>>/build-jit/./gcc/ -xc++
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../src/gcc/testsuite/selftests
make[4]: *** [../../src/gcc/c/Make-lang.in:124: s-selftest-c] Error 1
make[4]: *** Waiting for unfinished jobs....
cc1plus: internal compiler error: in operator[], at vec.h:867
mmap: Bad file descriptor
close: Bad file descriptor
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
make[4]: *** [../../src/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 1

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
             Target|                            |m68k
   Last reconfirmed|                            |2020-05-28
   Target Milestone|---                         |11.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
can we have a backtrace?

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Richard Biener from comment #1)
> can we have a backtrace?

Working on it.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to John Paul Adrian Glaubitz from comment #2)
> (In reply to Richard Biener from comment #1)
> > can we have a backtrace?
> 
> Working on it.

I'm at the point now where I can invoke the command which provokes the crash:

(sid-m68k-sbuild)root@epyc:/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/gcc#
/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/./gcc/xgcc
-B/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/./gcc/ -xc++
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../src/gcc/testsuite/selftests
cc1plus: internal compiler error: in operator[], at vec.h:867
mmap: Bad file descriptor
close: Bad file descriptor
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
(sid-m68k-sbuild)root@epyc:/build/gcc-snapshot-t0p5re/gcc-snapshot-20200525/build-jit/gcc#

What kind of backtrace are you looking for? Through GDB?

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
FWIW, I bootstrapped m68k within qemu on May30 with no testsuite regressions. 
Jun 6 also bootstrapped, but with some regressions with -fprofile-generate.

So clearly you're builds are doing something different than mine.

What Richi is asking for is a backtrace from the compiler itself.  Without that
or some way to reproduce the problem, then there's not much we can do.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Here's what I get on qemu-m68k-system (instead of qemu-user):

root@pacman:/srv/gcc-debug/build-jit/gcc# ./xgcc -B ./ -xc++ -nostdinc
/dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests
cc1plus: internal compiler error: in operator[], at vec.h:867
0x801e40f3 vec<constructor_elt, va_gc, vl_embed>::operator[](unsigned int)
        ../../src/gcc/vec.h:867
0x80e11f13 vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int)
        ../../src/gcc/tree.h:3296
0x80e11f13 vec<tree_node*, va_heap, vl_ptr>::operator[](unsigned int)
        ../../src/gcc/vec.h:1433
0x80e11f13 test_vector_cst_patterns
        ../../src/gcc/tree.c:15340
0x80e11f13 selftest::tree_c_tests()
        ../../src/gcc/tree.c:15853
0x812fd8fb selftest::run_tests()
        ../../src/gcc/selftest-run-tests.c:86
0x80ae443b toplev::run_self_tests()
        ../../src/gcc/toplev.c:2340
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
root@pacman:/srv/gcc-debug/build-jit/gcc#

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
That's an indication that something has tried to do an out of bounds read on a
VEC object.  The call chain points back to the initial quick_grow of an
auto_vec from test_vector_cst_patterns -- which is wildly surprising.

In fact if it were that broken I would fully expect other configurations,
including x86_64 to be failing miserably.  We're not seeing that.  I would also
expect that we could see the failure with a cross compiler, but that seems to
be working fine as well.

There's a nonzero chance this is actually a bug in the bootstrap compiler,
particularly if it's happening in the stage1 build.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Still broken?

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #8 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Richard Biener from comment #7)
> Still broken?

Unfortunately, yes:

> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=m68k&ver=1%3A20201002-1&stamp=1601807222&raw=0

echo timestamp > stmp-int-hdrs
/<<PKGBUILDDIR>>/build-jit/./gcc/xgcc -B/<<PKGBUILDDIR>>/build-jit/./gcc/ -xc
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../src/gcc/testsuite/selftests
/<<PKGBUILDDIR>>/build-jit/./gcc/xgcc -B/<<PKGBUILDDIR>>/build-jit/./gcc/ -xc++
-nostdinc /dev/null -S -o /dev/null
-fself-test=../../src/gcc/testsuite/selftests
cc1: internal compiler error: in operator[], at vec.h:880
mmap: Bad file descriptor
close: Bad file descriptor
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.
cc1plus: internal compiler error: in operator[], at vec.h:880
mmap: Bad file descriptor
close: Bad file descriptor
Please submit a full bug report,
with preprocessed source if appropriate.

I might try a full rebuild in a different environment.

gcc-10 builds fine, FWIW.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #9 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
I have bisected this now and it turns out, the regression was introduced by:

commit eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3
Author: Nick Clifton <nickc@redhat.com>
Date:   Mon Jun 18 10:39:01 2018 +0000

    Ensure that control characters in user supplied error and warning messages
are escaped.

            PR 84195
            * tree.c (escaped_string): New class.  Converts an unescaped
            string into its escaped equivalent.
            (warn_deprecated_use): Use the new class to convert the
            deprecation message, if present.
            (test_escaped_strings): New self test.
            (test_c_tests): Add test_escaped_strings.

    From-SVN: r261697

Interestingly, later SVN/git revisions still built fine, with 20191130 being
the last good one:

> https://buildd.debian.org/status/logs.php?pkg=gcc-snapshot&arch=m68k

I am building with the following command line:

../configure --with-gcc-major-version-only --program-prefix= --enable-shared
--enable-linker-build-id --disable-nls --enable-clocale=gnu
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libssp --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-objc-gc=auto
--enable-multiarch --disable-werror --disable-werror --disable-multilib
--enable-checking=yes --build=m68k-linux-gnu --host=m68k-linux-gnu
--target=m68k-linux-gnu --enable-languages=c++,jit --enable-host-shared
--disable-bootstrap && make -j64

from git. No local Debian patches applied.

My suspicion is that either this change triggers a bug in some external library
or a change in an external library made this bug visible.

Any suggestions? The only thing that it's odd on m68k is the 16-bit native
alignment, but I'm not sure whether that's relevant here.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
So if that bisection is accurate, the only way this could be failing would be
if something with a deprecated attribute is being used.

Maybe some printfs in warn_deprecated_use?  But again, I'm a bit surprised by
the bisection results.

http://3.14.90.209:8080/job/m68k-linux-gnu/

Has the most recent build results from my tester.  As you can see everything
built and regression tested on Dec 9.  Dec 15 had a successful bootstrap, but
glibc failed due to a relatively minor bug in glibc.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #11 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Jeffrey A. Law from comment #10)
> So if that bisection is accurate, the only way this could be failing would
> be if something with a deprecated attribute is being used.
> 
> Maybe some printfs in warn_deprecated_use?  But again, I'm a bit surprised
> by the bisection results.

I have verified it. I checked out eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3,
reproduced the problem. Then reverted the change and it worked again.

I honestly don't understand either how that commit could break the build.

> http://3.14.90.209:8080/job/m68k-linux-gnu/
> 
> Has the most recent build results from my tester.  As you can see everything
> built and regression tested on Dec 9.  Dec 15 had a successful bootstrap,
> but glibc failed due to a relatively minor bug in glibc.

Is that a native bootstrap on qemu with "jit" enabled?

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[law at redhat dot com]

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

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
On 12/30/20 10:30 AM, glaubitz at physik dot fu-berlin.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381
>
> --- Comment #11 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
> (In reply to Jeffrey A. Law from comment #10)
>> So if that bisection is accurate, the only way this could be failing would
>> be if something with a deprecated attribute is being used.
>>
>> Maybe some printfs in warn_deprecated_use?  But again, I'm a bit surprised
>> by the bisection results.
> I have verified it. I checked out eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3,
> reproduced the problem. Then reverted the change and it worked again.
>
> I honestly don't understand either how that commit could break the build.
>
>> http://3.14.90.209:8080/job/m68k-linux-gnu/
>>
>> Has the most recent build results from my tester.  As you can see everything
>> built and regression tested on Dec 9.  Dec 15 had a successful bootstrap,
>> but glibc failed due to a relatively minor bug in glibc.
> Is that a native bootstrap on qemu with "jit" enabled?
native bootstrap with qemu.  Don't offhand remember if jit is enabled. 
If not I can probably turn that on for the next one.
jeff

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
(In reply to Jeffrey A. Law from comment #12)
> On 12/30/20 10:30 AM, glaubitz at physik dot fu-berlin.de wrote:
> > Is that a native bootstrap on qemu with "jit" enabled?
>
> native bootstrap with qemu.  Don't offhand remember if jit is enabled. 
> If not I can probably turn that on for the next one.

Yes, that would be very helpful. I'll check whether enabling jit is actually
triggering it.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #14 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Quick update. The bug actually occurs with "--disable-bootstrap" which is how
Matthias Klose configures gcc when building the gcc-snapshot package. Removing
the configure flag makes the bootstrap succeed.

So my guess is that the system compiler is miscompiling stage1 which then fails
to build libstdc++ and only the stage2(3?) compiler works properly.

Guess we can mark this PR as invalid then?

PS: Happy New Year!

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[doko at debian dot org]

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

Matthias Klose <doko at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at debian dot org

--- Comment #15 from Matthias Klose <doko at debian dot org> ---
Jeff, this is a two-step build: First a build using the configure options in
comment #9, then a second build using the just built compiler for the jit build
with

CONFARGS_JIT := \
        $(filter-out --enable-languages=% \
                --enable-libstdcxx-debug %bootstrap,\
          $(CONFARGS)) \
        --enable-languages=c++,jit \
        --enable-host-shared \
        --disable-bootstrap

So maybe you can work around that by doing a bootstrap build for the second
build, but that wouldn't solve the problem of having a miscompiled build from
the first build?

[Bug target/95381] [11 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #16 from Jeffrey A. Law <law at redhat dot com> ---
I've been able to reproduce this.  It's either the enabling jit or host shared
libraries (which is required to enable jit).  It's faulting in the escaped
string tests which makes sense given John's bisection info.

I'm debugging in the background as this isn't anywhere near the top of my todo
list.

[Bug target/95381] [11 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug target/95381] [11/12 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

[Bug target/95381] [11/12 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3

[Bug target/95381] [11/12 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug target/95381] [11/12/13 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #20 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
JIT definitely works with 12 on m68k again - and probably 13. So, the title is
misleading.

[Bug target/95381] [11 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13 Regression]:      |[11 Regression]: Build
                   |Build fails with            |fails with
                   |--disable-bootstrap on m68k |--disable-bootstrap on m68k
                   |with ICE: in operator[], at |with ICE: in operator[], at
                   |vec.h:867                   |vec.h:867
                 CC|                            |egallager at gcc dot gnu.org
           Keywords|                            |build

--- Comment #21 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to John Paul Adrian Glaubitz from comment #20)
> JIT definitely works with 12 on m68k again - and probably 13. So, the title
> is misleading.

ok, retitled

[Bug target/95381] [11 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.