[Bug c/106972] New: internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 106972
   Summary: internal compiler error: in extract_insn, at
recog.c:2770 on ARMeb when building gcc itself
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

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=10 is S390 specific

[Bug target/106972] internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #2 from Thomas Petazzoni  ---
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.

[Bug target/106972] internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #5 from Thomas Petazzoni  ---
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.

[Bug target/107032] New: ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 107032
   Summary: ARM: libgcc2.c:2174:1: error: r7 cannot be used in
'asm' here
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

When building gcc 10.4.0 or 11.3.0 for Cortex-M3 or M7, the build fails with:

../../../libgcc/libgcc2.c: In function '__clear_cache':
../../../libgcc/libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
 2174 | }
  | ^
Makefile:501: recipe for target '_clear_cache.o' failed

GCC was configured like this:


(cd
/home/buildroot/autobuild/instance-0/output-1/build/host-gcc-initial-10.4.0/build
&& rm -rf config.cache;
PATH="/home/buildroot/autobuild/instance-0/output-1/host/bin:/home/buildroot/autobuild/instance-0/output-1/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
PKG_CONFIG="/home/buildroot/autobuild/instance-0/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/buildroot/autobuild/instance-0/output-1/host/lib/pkgconfig:/home/buildroot/autobuild/instance-0/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/buildroot/autobuild/instance-0/output-1/host/include"
CFLAGS="-O2 -I/home/buildroot/autobuild/instance-0/output-1/host/include"
CXXFLAGS="-O2 -I/home/buildroot/autobuild/instance-0/output-1/host/include"
LDFLAGS="-L/home/buildroot/autobuild/instance-0/output-1/host/lib
-Wl,-rpath,/home/buildroot/autobuild/instance-0/output-1/host/lib"
INTLTOOL_PERL=/usr/bin/perl CFLAGS="-O2
-I/home/buildroot/autobuild/instance-0/output-1/host/include"
LDFLAGS="-L/home/buildroot/autobuild/instance-0/output-1/host/lib
-Wl,-rpath,/home/buildroot/autobuild/instance-0/output-1/host/lib"
MAKEINFO=missing CFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -O0 -g0   -Wl,-elf2flt=-r -static"
CXXFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -O0 -g0   -Wl,-elf2flt=-r -static  -Wl,-elf2flt=-r
-static" AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib
CONFIG_SITE=/dev/null ./configure
--prefix="/home/buildroot/autobuild/instance-0/output-1/host"
--sysconfdir="/home/buildroot/autobuild/instance-0/output-1/host/etc"
--localstatedir="/home/buildroot/autobuild/instance-0/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=arm-buildroot-uclinux-uclibcgnueabi
--with-sysroot=/home/buildroot/autobuild/instance-0/output-1/host/arm-buildroot-uclinux-uclibcgnueabi/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float
--with-gmp=/home/buildroot/autobuild/instance-0/output-1/host
--with-mpc=/home/buildroot/autobuild/instance-0/output-1/host
--with-mpfr=/home/buildroot/autobuild/instance-0/output-1/host
--with-pkgversion="Buildroot 2022.05-439-g18f6e4bf70"
--with-bugurl="http://bugs.buildroot.net/"; --without-zstd --disable-libquadmath
--disable-libquadmath-support --disable-libsanitizer --disable-tls
--enable-threads --without-isl --without-cloog --with-float=soft
--with-abi="aapcs-linux" --with-cpu=cortex-m3 --with-float=soft
--with-mode=thumb --enable-languages=c --disable-shared --without-headers
--disable-threads --with-newlib --disable-largefile  )

Full build log of GCC 10.4.0 for Cortex-M3:
 
http://autobuild.buildroot.net/results/e91/e91fa76142cf50e514d5fe4791a06f3c3c014b5a/build-end.log

Full build log of GCC 11.3.0 for Cortex-M7:
 
http://autobuild.buildroot.net/results/9f7/9f7a43a375d476f47702cd7848eba53b76fcd386/build-end.log

[Bug target/106972] internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

[thomas.petazzoni--- via Gcc-bugs]

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

Thomas Petazzoni  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Thomas Petazzoni  ---
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.

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #2 from Thomas Petazzoni  ---
Thanks for the feedback. There must be something special in those
configurations, because I did build a Cortex-M4 configuration with gcc 11.3.0
just a few days ago, and it built fine.

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #4 from Thomas Petazzoni  ---
Yes, same triplet. We do not (yet) have FDPIC support for ARM in Buildroot (we
have a patch series pending for that).

[Bug bootstrap/107728] New: with -O0, libgcc in the first stage compiler has reference to libc functions

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 107728
   Summary: with -O0, libgcc in the first stage compiler has
reference to libc functions
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

We've started doing builds with -O0 in Buildroot, and we get build failures in
glibc that look like this:


/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__register_frame':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:138:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__register_frame_table':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:186:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__deregister_frame_info_bases':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:246:
undefined reference to `free'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `__deregister_frame':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:260:
undefined reference to `free'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `start_fde_sort':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:449:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:449:
undefined reference to `malloc'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `end_fde_sort':
/home/autobuild/autobuild/instance-11/output-1/build/host-gcc-initial-11.3.0/build/sh4eb-buildroot-linux-gnu/libgcc/../../../libgcc/unwind-dw2-fde.c:629:
undefined reference to `free'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/librtld.os:
in function `abort':
(.text+0x2345c): undefined reference to `__pthread_mutex_lock'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
(.text+0x23464): undefined reference to `__pthread_mutex_unlock'
/home/autobuild/autobuild/instance-11/output-1/host/lib/gcc/sh4eb-buildroot-linux-gnu/11.3.0/../../../../sh4eb-buildroot-linux-gnu/bin/ld:
(.text+0x2346c): undefined reference to `__pthread_mutex_lock'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:1339:
/home/autobuild/autobuild/instance-11/output-1/build/glibc-2.36-66-ga1dc0be03c9dd850b864bd7a9c03cf8e396eb7ca/build/elf/ld.so]
Error 1

See
http://autobuild.buildroot.net/results/7df/7df2d0648dd666dd07845614b34f59d6afba96c1/build-end.log
for a more complete build log.

The reason is that a number of functi

[Bug bootstrap/107728] with -O0, libgcc in the first stage compiler has reference to libc functions

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #3 from Thomas Petazzoni  ---
Thanks for the super quick feedback. Could you clarify "Move over, the
functions are not optimized out at -O2 but rather they don't get pulled in
glibc building because another function is referenced." ?

For the record, we are able to work around this issue by passing -O1 in
CFLAGS_FOR_TARGET/CXXFLAGS_FOR_TARGET when building the first stage gcc.

[Bug target/101737] New: SH4 -Os causes internal compiler error when building pixman

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 101737
   Summary: SH4 -Os causes internal compiler error when building
pixman
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

Created attachment 51247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51247&action=edit
source file that exhibits the issue

The attached source file test.c, which comes from the pixman open-source
project, when compiled for SuperH 4 using gcc 9.3.0 causes an internal compiler
error when built at -Os. Building at -O0 or -O2 doesn't cause any problem.

$ sh4-linux-gcc -c -Os test.c 
during RTL pass: split1
pixman-fast-path.c: In function
‘fast_composite_scaled_nearest__565_normal_OVER’:
pixman-fast-path.c:1204:1: internal compiler error: Segmentation fault
 1204 | FAST_NEAREST (_565_normal, , 0565, uint32_t, uint16_t, OVER,
NORMAL)
  | ^~
unrecognized DWARF version in .debug_info at 6
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ sh4-linux-gcc -c -O2 test.c 
$ sh4-linux-gcc -c -O0 test.c

[Bug target/101737] SH4 -Os causes internal compiler error when building pixman

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #1 from Thomas Petazzoni  ---
This still happens with gcc 11.1.0, with the exact same conditions.

[Bug target/101952] SH4 ICE: Error: unaligned opcodes detected in executable segment

[thomas.petazzoni--- via Gcc-bugs]

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

Thomas Petazzoni  changed:

   What|Removed |Added

 CC||thomas.petazzoni@free-elect
   ||rons.com

--- Comment #1 from Thomas Petazzoni  ---
Giulio: to help gcc developers, you should add a pre-processed version of the
file that exhibits the issue. It is a lot easier for them than running the
whole Buildroot build.

[Bug target/101915] Microblaze ICE: in extract_insn, at recog.c:2770

[thomas.petazzoni--- via Gcc-bugs]

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

Thomas Petazzoni  changed:

   What|Removed |Added

 CC||thomas.petazzoni@free-elect
   ||rons.com

--- Comment #3 from Thomas Petazzoni  ---
Giulio: please provide a pre-processed version of the file that causes the
build issue, so that gcc developers can be more easily reproduce. They are
probably not familiar with Buildroot, and it takes a while to do the whole
build. Thanks!

[Bug target/101916] SH4 ICE: Segmentation fault signal terminated program cc1

[thomas.petazzoni--- via Gcc-bugs]

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

Thomas Petazzoni  changed:

   What|Removed |Added

 CC||thomas.petazzoni@free-elect
   ||rons.com

--- Comment #1 from Thomas Petazzoni  ---
Giulio: please provide a pre-processed version of the file that causes the
build issue, so that gcc developers can be more easily reproduce. They are
probably not familiar with Buildroot, and it takes a while to do the whole
build. Thanks!

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #22 from Thomas Petazzoni  ---
Thanks for the patch, I confirm it fixes the build issue I was seeing!

[Bug libquadmath/116007] New: libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 116007
   Summary: libquadmath fails to build with
libgcc/soft-fp/quad.h:69:1: error: unable to emulate
'TF'
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

When GCC 14.1.0 is configured with:

./configure --prefix="/home/buildroot/autobuild/instance-3/output-1/host"
--sysconfdir="/home/buildroot/autobuild/instance-3/output-1/host/etc"
--enable-static  --target=powerpc64le-buildroot-linux-musl
--with-sysroot=/home/buildroot/autobuild/instance-3/output-1/host/powerpc64le-buildroot-linux-musl/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --enable-plugins --enable-lto
--with-gmp=/home/buildroot/autobuild/instance-3/output-1/host
--with-mpc=/home/buildroot/autobuild/instance-3/output-1/host
--with-mpfr=/home/buildroot/autobuild/instance-3/output-1/host
--with-pkgversion="Buildroot 2024.05-761-gc624eee120"
--with-bugurl="https://gitlab.com/buildroot.org/buildroot/-/issues";
--without-zstd --disable-libmpx --enable-libquadmath
--enable-libquadmath-support --disable-libsanitizer --enable-tls
--enable-threads --without-isl --without-cloog --with-cpu=power8
--enable-languages=c,fortran
--with-build-time-tools=/home/buildroot/autobuild/instance-3/output-1/host/powerpc64le-buildroot-linux-musl/bin
--disable-shared --disable-libgomp 

it fails to build with:

In file included from ../../../libquadmath/math/sqrtq.c:13:
../../../libquadmath/math/../../libgcc/soft-fp/quad.h:69:1: error: unable to
emulate 'TF'
   69 | typedef float TFtype __attribute__ ((mode (TF)));
  | ^~~

Full build log available at
http://autobuild.buildroot.net/results/8f5/8f585b83166d94772fe581f2efb0691676b33dab/build-end.log

Issue can be reproduced by doing:

$ git clone https://gitlab.com/buildroot.org/buildroot.git
$ cd buildroot
$ git checkout c624eee1 
$ wget -O .config
http://autobuild.buildroot.net/results/8f5/8f585b83166d94772fe581f2efb0691676b33dab/config
$ make

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #2 from Thomas Petazzoni  ---
(In reply to Andrew Pinski from comment #1)
> This might just be fixed on the trunk.

Thanks for the super fast feedback. Do you have a pointer to the commit fixing
this? I quickly looked at the recent changes in the master branch in the
libquadmath/ directory and couldn't spot anything that seemed related.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #6 from Thomas Petazzoni  ---
Thanks for all the feedback! However, I'm still a bit confused. In one comment
you say:

> From thbis, it seems powerpc musl likely doesn't have neither double double
> nor IEEE quad support and so in that case you can't use --enable-libquadmath
> --enable-libquadmath-support.

But then in the followup comment you point to
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=8d7be8d614ba028074597c3ab1ee12d9495fde09
which seems to be a fix for the PowerPC/musl case.

What should I understand?

Also, if something is not supported, shouldn't it bail out during the configure
stage, rather than later on at build time?

I'm realizing that we have this snippet of code in Buildroot:

# PowerPC64 big endian by default uses the elfv1 ABI, and PowerPC 64
# little endian by default uses the elfv2 ABI. However, musl has
# decided to use the elfv2 ABI for both, so we force the elfv2 ABI for
# Power64 big endian when the selected C library is musl.
ifeq ($(BR2_TOOLCHAIN_USES_MUSL)$(BR2_powerpc64),yy)
HOST_GCC_COMMON_CONF_OPTS += \
--with-abi=elfv2 \
--without-long-double-128
endif

in Buildroot, but that only applies to PowerPC 64 Big Endian. Our comment says
that elfv2 ABI is already the default for PowerPC 64 Little Endian, but perhaps
we also need something for PowerPC 64 Little Endian anyway ?

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #8 from Thomas Petazzoni  ---
(In reply to Jakub Jelinek from comment #7)
> That commit made --without-long-double-128 the default on
> powerpc*-*-linux-musl*.
> ELFv2 is one thing, but whether long double is IEEE double, IBM double
> double or IEEE quad is a separate thing.  You need to look at musl what it
> supports.
> E.g. glibc in the last few years for powerpc64le-linux supports all 3, on
> powerpc64-linux or powerpc-linux just IEEE double and IBM double double.

Thanks for your feedback. I wish I knew how to look into musl to understand
what it supports, but I honestly wouldn't know where to start. How do I find
out which one does musl support? I'm not even sure to understand the difference
between IEEE double, IEEE double double and IEEE quad.

[Bug target/116007] libquadmath fails to build with libgcc/soft-fp/quad.h:69:1: error: unable to emulate 'TF'

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #12 from Thomas Petazzoni  ---
Thanks for all the discussion, but I'm confused about what the conclusion
actually is. Could you help me understand what's the plan moving forward?

[Bug target/118280] [14/15 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #7 from Thomas Petazzoni  ---
(In reply to Joseph S. Myers from comment #6)
> Are you *actually using the code built by recent GCC versions on Microblaze
> hardware running the Linux kernel* (as opposed to simply building software
> for lots of different targets that GCC claims to support)?

I am merely one of the co-maintainers of Buildroot, and we don't know which
architectures our users are targeting. For sure we have many more users
targeting x86/ARM/ARM64/RISC-V than we have people targeting Microblaze. But I
don't really know for sure what is our user base on Microblaze.

I personally don't really care much: if gcc decides that Microblaze is declared
orphaned and no longer maintained (and I would certainly understand that),
Buildroot will simply follow that and drop support for Microblaze. However as
it stands today, Microblaze seems supported by gcc, hence this bug report.

[Bug target/118280] [14/15 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #5 from Thomas Petazzoni  ---
(In reply to Mikael Pettersson from comment #4)
> Note that a microblaze-unknown-linux-gnu toolchain builds just fine with
> gcc-14, glibc, and c++ enabled, so perhaps it's a _bit_ premature to
> deprecate it just because of these failures.

I confirm we have no problem building a Microblaze toolchain, but we have
serious issues building a large of software components with it due to this
atomic_test_and_set() problem.

[Bug target/118280] [14/15 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #11 from Thomas Petazzoni  ---
Is there any update about this patch? Should consider Microblaze
unmaintained/broken, and possibly drop support for it?

[Bug libstdc++/118280] New: undefined symbol __atomic_test_and_set in libstdc++.so on Microblaze

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 118280
   Summary: undefined symbol __atomic_test_and_set in libstdc++.so
on Microblaze
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

Since gcc 14.x, the libstdc++ library uses __atomic_test_and_set, and this
symbol isn't available on Microblaze, causing build failures such as:

configure:2557: checking for C++ compiler default output file name
configure:2579:
/home/thomas/buildroot/buildroot/outputs/gcc14-microblaze/host/bin/microblazeel-buildroot-linux-gnu-g++
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2 -g0 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  conftest.cpp 
>&5
/home/thomas/buildroot/buildroot/outputs/gcc14-microblaze/host/lib/gcc/microblazeel-buildroot-linux-gnu/14.2.0/../../../../microblazeel-buildroot-linux-gnu/bin/ld:
/home/thomas/buildroot/buildroot/outputs/gcc14-microblaze/host/lib/gcc/microblazeel-buildroot-linux-gnu/14.2.0/../../../../microblazeel-buildroot-linux-gnu/lib/libstdc++.so:
undefined reference to `__atomic_test_and_set'
collect2: error: ld returned 1 exit status
configure:2583: $? = 1
configure:2621: result:
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "acpitool"
| #define VERSION "0.5.1"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;

The exact same code builds fine with gcc 13.x.

Reproducer:

$ git clone https://gitlab.com/buildroot.org/buildroot.git
$ cat > .config<

[Bug target/118280] undefined symbol __atomic_test_and_set in libstdc++.so on Microblaze

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #1 from Thomas Petazzoni  ---
Actually the issue is not just libstdc++. libatomic.so also uses
__atomic_test_and_set(), and that causes build failures since GCC 14.x. For
example when building linux-pam on Microblaze:

/home/buildroot/instance-0/output-1/per-package/linux-pam/host/opt/ext-toolchain/bin/../lib/gcc/microblaze-buildroot-linux-musl/14.2.0/../../../../microblaze-buildroot-linux-musl/bin/ld:
/home/buildroot/instance-0/output-1/per-package/linux-pam/host/opt/ext-toolchain/bin/../lib/gcc/microblaze-buildroot-linux-musl/14.2.0/../../../../microblaze-buildroot-linux-musl/lib/libatomic.so:
undefined reference to `__atomic_test_and_set'

Full log at
http://autobuild.buildroot.net/results/0a3/0a34e6403495c33f34c16fef211da5df2ac3437a/build-end.log

[Bug target/118280] [14/15 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #13 from Thomas Petazzoni  ---
(In reply to Michael Eager from comment #12)
> If you have a patch, please send it to gcc-patc...@gcc.gnu.org

Hm, I'm sorry, but I don't have a patch. My previous comment should have said
"Is there any update about this bug". Sorry the mistake.

[Bug target/118280] [14/15 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #15 from Thomas Petazzoni  ---
(In reply to Michael Eager from comment #14)
> There is no reproducible test case in this bug report.  A report that
> buildroot has a build error is not a test case.

I'm not sure how to provide a reproducible test case without using Buildroot.

If you know how to cross-compile gcc for Microblaze, then if you just
cross-compile for Microblaze and build pretty much any C++ program, you'll
reproduce the issue.

> Creating a patch which only addressed the build failure would be
> problematic:  there would be no testing to verify that _atomic_test_and_set
> worked correctly.

I'm not interested in fixing just the build failure of course, but by a
complete fix that also works at runtime.

[Bug target/118280] [14/15/16 Regression] __atomic_test_and_set in Microblaze are broken (exposed by r14-4286)

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #16 from Thomas Petazzoni  ---
Now that GCC 15.1 is out, I was wondering if this issue has somehow been
resolved?

[Bug target/107032] ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

[thomas.petazzoni--- via Gcc-bugs]

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

--- Comment #9 from Thomas Petazzoni  ---
FYI, this is still happening at least with GCC 13.3.0. We got again the build
issue in our autobuilder today:

https://autobuild.buildroot.org/results/f37b03dc47da8f54c583b33cac960daeed72c29f/build-end.log