Bug 106972 - internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself
Summary: internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when build...
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 11.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-20 06:24 UTC by Thomas Petazzoni
Modified: 2022-10-23 00:37 UTC (History)
0 users

See Also:
Host:
Target: armeb-buildroot-linux-gnueabi
Build:
Known to work:
Known to fail:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Petazzoni 2022-09-20 06:24:19 UTC 
When building gcc 11.3.0 for armeb, with the following configure command line:


(cd /home/thomas/autobuild/instance-1/output-1/build/host-gcc-initial-11.3.0/build && rm -rf config.cache; PATH="/home/thomas/autobuild/instance-1/output-1/host/bin:/home/thomas/autobuild/instance-1/output-1/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" PKG_CONFIG="/home/thomas/autobuild/instance-1/output-1/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 PKG_CONFIG_LIBDIR="/home/thomas/autobuild/instance-1/output-1/host/lib/pkgconfig:/home/thomas/autobuild/instance-1/output-1/host/share/pkgconfig" AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm" CC="/usr/bin/gcc" GCC="/usr/bin/gcc" CXX="/usr/bin/g++" CPP="/usr/bin/cpp" OBJCOPY="/usr/bin/objcopy" RANLIB="/usr/bin/ranlib" CPPFLAGS="-I/home/thomas/autobuild/instance-1/output-1/host/include" CFLAGS="-O2 -I/home/thomas/autobuild/instance-1/output-1/host/include" CXXFLAGS="-O2 -I/home/thomas/autobuild/instance-1/output-1/host/include" LDFLAGS="-L/home/thomas/autobuild/instance-1/output-1/host/lib -Wl,-rpath,/home/thomas/autobuild/instance-1/output-1/host/lib" INTLTOOL_PERL=/usr/bin/perl CFLAGS="-O2 -I/home/thomas/autobuild/instance-1/output-1/host/include" LDFLAGS="-L/home/thomas/autobuild/instance-1/output-1/host/lib -Wl,-rpath,/home/thomas/autobuild/instance-1/output-1/host/lib" MAKEINFO=missing CFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1" CXXFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0 -D_FORTIFY_SOURCE=1" AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib CONFIG_SITE=/dev/null ./configure --prefix="/home/thomas/autobuild/instance-1/output-1/host" --sysconfdir="/home/thomas/autobuild/instance-1/output-1/host/etc" --localstatedir="/home/thomas/autobuild/instance-1/output-1/host/var" --enable-shared --disable-static --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs --disable-documentation --disable-debug --with-xmlto=no --with-fop=no --disable-nls --disable-dependency-tracking  --target=armeb-buildroot-linux-gnueabi --with-sysroot=/home/thomas/autobuild/instance-1/output-1/host/armeb-buildroot-linux-gnueabi/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --enable-plugins --enable-lto --with-gmp=/home/thomas/autobuild/instance-1/output-1/host --with-mpc=/home/thomas/autobuild/instance-1/output-1/host --with-mpfr=/home/thomas/autobuild/instance-1/output-1/host --with-pkgversion="Buildroot 2022.08-rc1-468-g0f42b81532" --with-bugurl="http://bugs.buildroot.net/" --without-zstd --disable-libquadmath --disable-libquadmath-support --enable-tls --enable-threads --without-isl --without-cloog --with-float=soft --with-abi="aapcs-linux" --with-cpu=iwmmxt --with-float=soft --with-mode=arm --enable-languages=c --disable-shared --without-headers --disable-threads --with-newlib --disable-largefile  )

The build fails with:

../../../libgcc/config/arm/unwind-arm.c:467:1: error: unrecognizable insn:
  467 | }
      | ^
(insn 2 4 3 2 (set (reg/v/f:SI 118 [ p ])
        (reg:SI 0 r0 [ p ])) "../../../libgcc/config/arm/unwind-arm.c":456:1 -1
     (nil))
during RTL pass: vregs
../../../libgcc/config/arm/unwind-arm.c:467:1: internal compiler error: in extract_insn, at recog.c:2770

(The same error happens in several place)

Full build log at http://autobuild.buildroot.net/results/8e4c4512902c34d8ec0c6f8dfff92b7a198e4b4a/build-end.log

There are a number of similar reports, but they don't seem to apply:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99724 is already fixed in gcc 11.3.0
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102222 is S390 specific
Comment 1 Andrew Pinski 2022-09-20 06:32:33 UTC 
iwmmxt support is definitely bitrotten and most likely should be removed from GCC.
Comment 2 Thomas Petazzoni 2022-09-20 06:48:40 UTC 
Thanks for the quick feedback! I am not super familiar with iwmmxt, but as I understand it is used in Marvell PXA270 and above. While these are fairly old indeed, their support is still maintained in the upstream Linux kernel, so it would be odd to no longer have gcc support for them.
Comment 3 Andrew Pinski 2022-09-20 06:54:11 UTC 
(In reply to Thomas Petazzoni from comment #2)
> Thanks for the quick feedback! I am not super familiar with iwmmxt, but as I
> understand it is used in Marvell PXA270 and above. While these are fairly
> old indeed, their support is still maintained in the upstream Linux kernel,
> so it would be odd to no longer have gcc support for them.

Marvell does not provide any support for them in the last 4 years or more. With my Marvell hat on, it makes sense to remove the GCC support as it definitely has bitrotten and I have no resources at all to do any upstream fixes for it.
Comment 4 Richard Earnshaw 2022-09-20 14:52:52 UTC 
I don't think we're talking about removing support for the CPU, just support for the iwmmxt extension.  That is, you can still use it as an Arm cpu, but without the vector engine.
Comment 5 Thomas Petazzoni 2022-09-20 15:00:49 UTC 
ACK, but what we're using in this configuration is --with-cpu=iwmmxt. I'm a bit confused between it being a CPU type, and it being just a vector extension.
Comment 6 Richard Earnshaw 2022-09-20 15:10:14 UTC 
Nobody has proposed any patches yet, but I imagine we'd end up treating -mcpu=iwmmxt[2] in the same way as -mcpu=xscale.  Similarly for -march=iwmmxt[2].
Comment 7 Thomas Petazzoni 2022-09-25 19:43:34 UTC 
Thanks for the feedback. We have disabled support for iwmmxt in Buildroot, so this issue is no longer a problem for us. I will therefore close, marking as WONTFIX, as it was indicated that this would not be fixed.