[Bug middle-end/100262] warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100262 --- Comment #6 from Romain Naour --- Hello, Thanks for the help and confirm that's a problem on the existing code, not on gcc. Best regards, Romain
[Bug c/100262] warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100262 --- Comment #3 from Romain Naour --- Created attachment 50677 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50677=edit arch/sparc/kernel/mdesc.o generated with gcc -E
[Bug c/100262] warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100262 --- Comment #1 from Romain Naour --- Seems related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
[Bug c/100262] New: warning on sparc64: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100262
Bug ID: 100262
Summary: warning on sparc64: 'strcmp' reading 1 or more bytes
from a region of size 0 [-Werror=stringop-overread]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: romain.naour at gmail dot com
Target Milestone: ---
Hello,
Using GCC 11.1.0-RC-20210423 for building sparc64 kernel fail to build due to
-Werror=stringop-overread:
arch/sparc/kernel/mdesc.c: In function 'mdesc_node_by_name':
arch/sparc/kernel/mdesc.c:647:22: error: 'strcmp' reading 1 or more bytes from
a region of size 0 [-Werror=stringop-overread]
647 | if (!strcmp(names + ep[ret].name_offset, name))
| ^
arch/sparc/kernel/mdesc.c:77:33: note: at offset 16 into source object 'mdesc'
of size 16
77 | struct mdesc_hdrmdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_get_property':
arch/sparc/kernel/mdesc.c:692:22: error: 'strcmp' reading 1 or more bytes from
a region of size 0 [-Werror=stringop-overread]
692 | if (!strcmp(names + ep->name_offset, name)) {
| ^
arch/sparc/kernel/mdesc.c:77:33: note: at offset 16 into source object 'mdesc'
of size 16
77 | struct mdesc_hdrmdesc;
| ^
arch/sparc/kernel/mdesc.c: In function 'mdesc_next_arc':
arch/sparc/kernel/mdesc.c:719:21: error: 'strcmp' reading 1 or more bytes from
a region of size 0 [-Werror=stringop-overread]
719 | if (strcmp(names + ep->name_offset, arc_type))
| ^
arch/sparc/kernel/mdesc.c:77:33: note: at offset 16 into source object 'mdesc'
of size 16
77 | struct mdesc_hdrmdesc;
| ^
cc1: all warnings being treated as errors
See:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/sparc/kernel/mdesc.c?h=v5.12#n647
I'm not sure if we need to update the mdesc.c code or disable the warning.
[Bug target/98784] [8/9/10/11 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #10 from Romain Naour --- (In reply to Eric Botcazou from comment #8) > > OK, this makes sense now and this looks like a bootstrap problem, e.g. the > > code setting up _GLOBAL_OFFSET_TABLE_ in the libc might be trying to access > > it or something along this line. > > I misremembered: the code loading the GOT register is eliminated if not used > in the end, but it can block the leaf register optimization, i.e. a register > window is allocated although it is not needed. So does uClibc depend on the > fact that a register window is not allocated in some specific spot? Since some part of uClibc code come from glibc, I'm trying to compare with glibc 2.30... but there are some differences. For example there is no SETUP_PIC_REG_LEAF definition for sparc32 in uClubc: (SETUP_PIC_REG_LEAF use internally _GLOBAL_OFFSET_TABLE_) https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/sparc/sysdep.h?id=ab1dd83bec59c9e65c31efd6e887182948f627be https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/sparc/sysdep.h;h=31a8addebcbeec2f60ece377677bc2be137b3664;hb=d811d240c06a8191db88ad4f1e60e1b672e4cc66 The uClibc code doesn't seems up-to-date with the glibc version... But I can't try to reproduce the issue with glibc since the support for sparc has been removed from Buildroot since a long time and from glibc for sparcv8 since 2.31: https://lwn.net/Articles/811275/ resync the sparc port for uclibc with glibc requires a lot of work. Best regards, Romain
[Bug target/98784] [8/9/10/11 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #9 from Romain Naour --- (In reply to Eric Botcazou from comment #7) > > The previous gcc command line was from the busybox build (without -fPIC) but > > this is not busybox that crash... this is the libc. > > > > See how the libc (uClibc) was built: > > > > output/host/bin/sparc-buildroot-linux-uclibc-gcc -c libc/stdlib/atoll.c -o > > libc/stdlib/atoll.os -Wall -Wstrict-prototypes -Wstrict-aliasing > > -Wno-nonnull-compare -funsigned-char -fno-builtin -fcommon -fno-asm > > -fmerge-all-constants -std=gnu99 -mcpu=v8 -fno-stack-protector -nostdinc > > -I./include -I./include -include libc-symbols.h -I./libc/sysdeps/linux/sparc > > -I./libc/sysdeps/linux -I./ldso/ldso/sparc -I./ldso/include -I. -Os > > -fstrict-aliasing -D__USE_STDIO_FUTEXES__ -DHAVE_FORCED_UNWIND > > -D_LIBC_REENTRANT -I./libpthread/nptl -I./libpthread/nptl > > -I./libpthread/nptl/sysdeps/unix/sysv/linux/sparc > > -I./libpthread/nptl/sysdeps/sparc -I./libpthread/nptl/sysdeps/sparc > > -I./libpthread/nptl/sysdeps/unix/sysv/linux > > -I./libpthread/nptl/sysdeps/unix/sysv/linux > > -I./libpthread/nptl/sysdeps/pthread -I./libpthread/nptl/sysdeps/pthread/bits > > -I./libpthread/nptl/sysdeps/generic -I./libc/sysdeps/linux/common -isystem > > output/host/lib/gcc/sparc-buildroot-linux-uclibc/10.2.0/include-fixed > > -isystem output/host/lib/gcc/sparc-buildroot-linux-uclibc/10.2.0/include > > -Ioutput/build/linux-headers-5.4.88/usr/include/ -DNDEBUG -DIN_LIB=libc > > -fPIC -MT libc/stdlib/atoll.os -MD -MP -MF libc/stdlib/.atoll.os.dep > > > > Indeed we have "-fPIC" > > OK, this makes sense now and this looks like a bootstrap problem, e.g. the > code setting up _GLOBAL_OFFSET_TABLE_ in the libc might be trying to access > it or something along this line. > > Can you find out which module of uClibc sets up _GLOBAL_OFFSET_TABLE_ and > confirm that it is compiled with -fPIC as well? If so, would it be possible > *not* to compile with -fPIC? There is an option [1] to build all of uClibc as PIC objects but some other part are build unconditionally as PIC objects. This option us always set in the Buildroot's uClibc configuration. By disabling this option doesn't make any diffrence. Removing -fPIC in Makefiles produce a non working libc. [1] https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/extra/Configs/Config.in?id=ab1dd83bec59c9e65c31efd6e887182948f627be#n296
[Bug target/98784] [8/9/10/11 Regression] sparcv8 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #6 from Romain Naour --- Hello, Thanks for the help, The previous gcc command line was from the busybox build (without -fPIC) but this is not busybox that crash... this is the libc. See how the libc (uClibc) was built: output/host/bin/sparc-buildroot-linux-uclibc-gcc -c libc/stdlib/atoll.c -o libc/stdlib/atoll.os -Wall -Wstrict-prototypes -Wstrict-aliasing -Wno-nonnull-compare -funsigned-char -fno-builtin -fcommon -fno-asm -fmerge-all-constants -std=gnu99 -mcpu=v8 -fno-stack-protector -nostdinc -I./include -I./include -include libc-symbols.h -I./libc/sysdeps/linux/sparc -I./libc/sysdeps/linux -I./ldso/ldso/sparc -I./ldso/include -I. -Os -fstrict-aliasing -D__USE_STDIO_FUTEXES__ -DHAVE_FORCED_UNWIND -D_LIBC_REENTRANT -I./libpthread/nptl -I./libpthread/nptl -I./libpthread/nptl/sysdeps/unix/sysv/linux/sparc -I./libpthread/nptl/sysdeps/sparc -I./libpthread/nptl/sysdeps/sparc -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/unix/sysv/linux -I./libpthread/nptl/sysdeps/pthread -I./libpthread/nptl/sysdeps/pthread/bits -I./libpthread/nptl/sysdeps/generic -I./libc/sysdeps/linux/common -isystem output/host/lib/gcc/sparc-buildroot-linux-uclibc/10.2.0/include-fixed -isystem output/host/lib/gcc/sparc-buildroot-linux-uclibc/10.2.0/include -Ioutput/build/linux-headers-5.4.88/usr/include/ -DNDEBUG -DIN_LIB=libc -fPIC -MT libc/stdlib/atoll.os -MD -MP -MF libc/stdlib/.atoll.os.dep Indeed we have "-fPIC" The system boot correctly if I replace the libc library with a working one. I'm not familiar with gcc internals but I tried to remove "!optimize" from the if clauses [1] : "if (!flag_pic || !crtl->uses_pic_offset_table)" It seems to work (ok probably not the correct fix). Is the issue related to the optimization level (Os vs O1) ? [1] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/sparc/sparc.c;h=aefced85fe142885b1b31fa878a0ff0dfd4e921a;hb=ee5c3db6c5b2c3332912fb4c9cfa2864569ebd9a#l13097
[Bug target/98784] [8/9/10/11 Regression] sparcv8 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #4 from Romain Naour --- (In reply to Eric Botcazou from comment #3) > > So -fPIE is not used here but there is a side effect when the patch is > > applied. > > You need to look at the output of 'gcc -v' to be sure of that. output/host/bin/sparc-buildroot-linux-uclibc-gcc -v Using built-in specs. COLLECT_GCC=/output/host/bin/sparc-buildroot-linux-uclibc-gcc.br_real COLLECT_LTO_WRAPPER=/output/host/libexec/gcc/sparc-buildroot-linux-uclibc/10.2.0/lto-wrapper Target: sparc-buildroot-linux-uclibc Configured with: ./configure --prefix=/output/host --sysconfdir=/output/host/etc --enable-static -q --target=sparc-buildroot-linux-uclibc --with-sysroot=/output/host/sparc-buildroot-linux-uclibc/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=output/host --with-mpc=output/host --with-mpfr=output/host --with-pkgversion='Buildroot 2020.11-999-g57d61a3986' --with-bugurl=http://bugs.buildroot.net/ --without-zstd --disable-libitm --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --disable-libsanitizer --enable-tls --enable-threads --without-isl --without-cloog --with-cpu=v8 --enable-languages=c,c++ --with-build-time-tools=/output/host/sparc-buildroot-linux-uclibc/bin --enable-shared --disable-libgomp --silent Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (Buildroot 2020.11-999-g57d61a3986) I can't give more debug info since all program segfault, even gdb or gdbserver.
[Bug c/98784] [gcc 8.4/9.3/10] sparcv8 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #2 from Romain Naour --- Hello, The kernel and userland are built with the same toolchain, but this is the userpace program (such busybox) that crash. Busybox is built with the following flags: Toolchain wrapper executing: 'qemu_sparc_ss10_defconfig/host/bin/sparc-buildroot-linux-uclibc-gcc.br_real' '--sysroot' 'qemu_sparc_ss10_defconfig/host/sparc-buildroot-linux-uclibc/sysroot' '-Wp,-MD,libbb/.vfork_daemon_rexec.o.d' '-std=gnu99' '-Iinclude' '-Ilibbb' '-include' 'include/autoconf.h' '-D_GNU_SOURCE' '-DNDEBUG' '-D_LARGEFILE_SOURCE' '-D_LARGEFILE64_SOURCE' '-D_FILE_OFFSET_BITS=64' '-DBB_VER="1.33.0"' '-D_LARGEFILE_SOURCE' '-D_LARGEFILE64_SOURCE' '-D_FILE_OFFSET_BITS=64' '-Os' '-Wall' '-Wshadow' '-Wwrite-strings' '-Wundef' '-Wstrict-prototypes' '-Wunused' '-Wunused-parameter' '-Wunused-function' '-Wunused-value' '-Wmissing-prototypes' '-Wmissing-declarations' '-Wno-format-security' '-Wdeclaration-after-statement' '-Wold-style-definition' '-finline-limit=0' '-fno-builtin-strlen' '-fomit-frame-pointer' '-ffunction-sections' '-fdata-sections' '-fno-guess-branch-probability' '-funsigned-char' '-static-libgcc' '-falign-functions=1' '-falign-jumps=1' '-falign-labels=1' '-falign-loops=1' '-fno-unwind-tables' '-fno-asynchronous-unwind-tables' '-fno-builtin-printf' '-Os' '-DKBUILD_BASENAME="vfork_daemon_rexec"' '-DKBUILD_MODNAME="vfork_daemon_rexec"' '-c' '-o' 'libbb/vfork_daemon_rexec.o' 'libbb/vfork_daemon_rexec.c' So -fPIE is not used here but there is a side effect when the patch is applied. Note: This is an initial report, I don't have any clue about the real issue. Best regards, Romain
[Bug c/98784] New: [gcc 8.4/9.3/10] sparcv8 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 Bug ID: 98784 Summary: [gcc 8.4/9.3/10] sparcv8 regression Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: romain.naour at gmail dot com Target Milestone: --- Hello, When building a rootfs for sparcv8 using the Buildroot defconfig qemu_sparc_ss10_defconfig, the system produce some illegal instruction messages. gcc 8.3, 9.2 are the latest working gcc version. git bisect between gcc 8.3 and 8.4 allowed to identify the commit that introduced the regression: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0a83f1a441d7aaadecb368c237b6ee70bd7b91d6 The commit has been introduced to fix the following bub: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 It has been backported to gcc 8.4 and 9.3. Reverting this patch allowed to produce a working rootfs. This issue can be reproduced using the following steps: $ git://git.busybox.net/buildroot $ cd buildroot/ $ git checkout 2020.11.1 $ make qemu_sparc_ss10_defconfig $ make $ ./output/images/start-qemu.sh The kernel boot correctly but the login program (busybox) crash while trying to login: [...] Starting syslogd: Welcome to Buildroot buildroot login: root Welcome to Buildroot buildroot login: root For now, It's just a basic test that allow to reproduce the issue. We can use a shell instead of init program but even with a simple command such 'ls' the system crash: sh-5.0# ls CPU: 0 PID: 1 Comm: sh Not tainted 4.19.16 #1 [f0022fbc : do_exit+0x948/0x968 ] [f000afec : do_signal+0x5f8/0x79c ] [f000b4b4 : do_notify_resume+0x48/0x58 ] [f0008c88 : signal_p+0x14/0x24 ] [0004b874 : 0x4b874 ] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004 Best regards, Romain
[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095 Romain Naour changed: What|Removed |Added CC||romain.naour at gmail dot com --- Comment #9 from Romain Naour --- Hello, This patch produce a regression on sparcv8 SS10 platform. In Buildroot we have a defconfig qemu_sparc_ss10_defconfig that was working (booting) with gcc 7.4, 8.3 and 9.2. But it doesn't boot anymore with gcc 8.4, 9.3 and 10.2. I reverted this patch to be able to boot the system. See: http://patchwork.ozlabs.org/project/buildroot/patch/20210120230234.2086807-1-romain.na...@gmail.com/ Best regards, Romain
[Bug c/97208] [gcc 10.2.0] Microblaze regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97208 --- Comment #1 from Romain Naour --- Hello, I had to disable -ftree-loop-distribute-patterns while building the kernel on microblaze (using -Os). The regression appear since the commit [1] that moved -ftree-loop-distribute-patterns from -O3 to -O2 (-Os) optimization level. I guess this behavior change should be documented in the gcc 10 changes page [2]? [1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=5879ab5fafedc8f6f9bfe95a4cf8501b0df90edd [2] https://gcc.gnu.org/gcc-10/changes.html Best regards, Romain
[Bug c/97208] New: [gcc 10.2.0] Microblaze regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97208 Bug ID: 97208 Summary: [gcc 10.2.0] Microblaze regression Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: romain.naour at gmail dot com Target Milestone: --- Hello, Toolchains using gcc 10.2.0 targeting Microblaze architecture are not able to build a bootable Linux kernel 5.4.58 under Qemu (5.0.0). https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359542 (glibc) https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359544 (musl) https://gitlab.com/bootlin/toolchains-builder/-/jobs/729359546 (uclibc-ng) Toolchain components versions: GCC 10.2 binutils 2.34 kernel headers 5.4.58 The same system boot as soon as gcc 9.3 is used. Best regards, Romain
[Bug bootstrap/61164] GCC 4.9.0 fails to build libitm when fortification enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164 Romain Naour changed: What|Removed |Added CC||romain.naour at gmail dot com --- Comment #6 from Romain Naour --- Hi, This issue has been reported recently on gcc 5.5.0 [1] Is it safe to backport the patch to gcc 4.9 and 5.5.0? Best regards, Romain [1] https://bugs.busybox.net/show_bug.cgi?id=11476
[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180 Romain Naour changed: What|Removed |Added CC||romain.naour at gmail dot com --- Comment #18 from Romain Naour --- (In reply to Richard Biener from comment #17) > (In reply to romain.naour from comment #16) > > Hi, > > > > gcc 7.3.0 is affected by this bug but only on microblaze architecture, see > > [1]. > > Do you plan to backport this patch on gcc 7.x? > > It is safe to do so without take the risk to break something with other > > architecture or optimization level? > > > > Best regards, > > Romain > > > > [1] http://lists.busybox.net/pipermail/buildroot/2018-April/220156.html > > The bug isn't a regression so technically it doesn't qualify. OTOH it > looks reasonably safe to backport and the bug is annoying. Jakub, would > you be ok with a backport? Ping?
