[Bug driver/115368] Wrong order of gcc include paths on musl systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115368 Khem Raj changed: What|Removed |Added Attachment #58366|0 |1 is obsolete|| --- Comment #2 from Khem Raj --- Created attachment 58370 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58370&action=edit potential fix v2
[Bug driver/115368] Wrong order of gcc include paths on musl systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115368 --- Comment #1 from Khem Raj --- Created attachment 58366 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58366&action=edit potential fix This patch uses -idirafter instead of -iprefix when building for musl. This fixes the issue as the search paths get adjusted and sysroot is searched before gcc headers dir.
[Bug driver/115368] New: Wrong order of gcc include paths on musl systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115368 Bug ID: 115368 Summary: Wrong order of gcc include paths on musl systems Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- When doing cross-builds targeting musl based systems, gcc driver adds -iprefix to cc1/cc1plus call, the path is based on gcc cross compiler installation location, and points to GCC private headers which override some of system headers e.g. stddef.h stdint.h, stdarg.h to name a few. This works ok with glibc based systems but musl does not depend/use gcc's private headers [1] and -iprefix prepends to search path which means the headers from gcc installation will be picked up first. This causes problems e.g. when configuring python build, it tries to detect platform and logic to detect musl system is based on musl specific define coming from stdarg.h, however musl cross gcc feeds the gcc's own stdarg.h header and the test fails. [1] https://gitlab.alpinelinux.org/alpine/aports/-/issues/12477#note_145159
[Bug target/115042] New: valgrind test fails to compile on armv7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115042
Bug ID: 115042
Summary: valgrind test fails to compile on armv7
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
Created attachment 58180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58180&action=edit
testcase
Attached test comes from valgrind, it worked fine with gcc-13 but can not be
built with gcc-14 or trunk with -O0, if any other -O is used then it
compiles ok but valgrind uses -O0 for this given testcase.
arm-yoe-linux-gnueabi/arm-yoe-linux-gnueabi-gcc -mthumb -mfpu=neon
-mfloat-abi=hard -mcpu=cortex-a15 -no-pie -fno-PIE -O0 v6media.i -c
v6media.c:5905:40: error: 'asm' operand has impossible constraints or there are
not enough registers
5905 | TESTINST4("smlaltt r0, r1, r2, r3",
|^
...
[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl or if ifunc support is disabled (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #5 from Khem Raj --- (In reply to Wilco from comment #4) > Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646408.html FWIW, v2 of this patch worked fine on Yocto/qemuarm64/musl build. Run tests have not been completed yet but it looks promising.
[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #17 from Khem Raj --- @wilco this commit is now regressing builds for musl/aarch64, where libatomic fails to compile. With errors like In file included from /home/kraj/work/gcc/libatomic/exch_n.c:25: /home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error: ‘export_exchange_16’ aliased to undefined symbol ‘libat_exchange_16’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ |^~~ /home/kraj/work/gcc/libatomic/libatomic_i.h:40:25: note: in definition of macro ‘C2_’ 40 | #define C2_(X,Y)X ## Y | ^ /home/kraj/work/gcc/libatomic/libatomic_i.h:288:37: note: in expansion of macro ‘C2’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ | ^~ /home/kraj/work/gcc/libatomic/exch_n.c:128:1: note: in expansion of macro ‘EXPORT_ALIAS’ 128 | EXPORT_ALIAS (SIZE(exchange)); | ^~~~ In file included from /home/kraj/work/gcc/libatomic/fop_n.c:25, from /home/kraj/work/gcc/libatomic/fand_n.c:3: /home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error: ‘export_fetch_and_16’ aliased to undefined symbol ‘libat_fetch_and_16’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ |^~~ /home/kraj/work/gcc/libatomic/libatomic_i.h:40:25: note: in definition of macro ‘C2_’ 40 | #define C2_(X,Y)X ## Y | ^ /home/kraj/work/gcc/libatomic/libatomic_i.h:288:37: note: in expansion of macro ‘C2’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ | ^~ /home/kraj/work/gcc/libatomic/fop_n.c:199:1: note: in expansion of macro ‘EXPORT_ALIAS’ 199 | EXPORT_ALIAS (SIZE(C2(fetch_,NAME))); | ^~~~ In file included from /home/kraj/work/gcc/libatomic/fadd_n.c:25: /home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error: ‘export_fetch_add_16’ aliased to undefined symbol ‘libat_fetch_add_16’ 288 | extern typeof(C2(libat_,X)) C2(export_,X) \ |^~~
[Bug target/110901] -march does not override -mcpu on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901 --- Comment #2 from Khem Raj --- (In reply to Andrew Pinski from comment #1) > Order matters. In this case -march is after -mcpu ... It does not seem to be effective in this case. I tried to specify -mcpu after -march and vice-versa, result is same % ../recipe-sysroot-native/usr/bin/aarch64-yoe-linux/aarch64-yoe-linux-gcc -mbranch-protection=standard --sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-cortexa53-crypto-yoe-linux/glibc/2.38-r0/recipe-sysroot -fuse-ld=bfd -c -march=armv8.2-a+sve -mcpu=cortex-a72.cortex-a53 a.s a.s: Assembler messages: a.s:2: Error: selected processor does not support `ptrue p0.b' ../recipe-sysroot-native/usr/bin/aarch64-yoe-linux/aarch64-yoe-linux-gcc -mbranch-protection=standard --sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-cortexa53-crypto-yoe-linux/glibc/2.38-r0/recipe-sysroot -fuse-ld=bfd -c -mcpu=cortex-a72.cortex-a53 -march=armv8.2-a+sve a.s a.s: Assembler messages: a.s:2: Error: selected processor does not support `ptrue p0.b'
[Bug driver/110901] New: -march does not override -mcpu on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901 Bug ID: 110901 Summary: -march does not override -mcpu on aarch64 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- As per https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#index-mcpu When -march is used then relevant part of -mcpu are overridden by that. However this seems to be not happening in following case with GCC13 a.s === .text ptrue p0.b = aarch64-yoe-linux-gcc -mcpu=cortex-a72.cortex-a53 -mbranch-protection=standard --sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-cortexa53-crypto-yoe-linux/glibc/2.38-r0/recipe-sysroot -fuse-ld=bfd -c -march=armv8.2-a+sve a.s -v Using built-in specs. COLLECT_GCC=../recipe-sysroot-native/usr/bin/aarch64-yoe-linux/aarch64-yoe-linux-gcc Target: aarch64-yoe-linux Configured with: ../../../../../../work-shared/gcc-13.2.0-r0/gcc-13.2.0/configure --build=x86_64-linux --host=x86_64-linux --target=aarch64-yoe-linux --prefix=/host-native/usr --exec_prefix=/host-native/usr --bindir=/host-native/usr/bin/aarch64-yoe-linux --sbindir=/host-native/usr/bin/aarch64-yoe-linux --libexecdir=/host-native/usr/libexec/aarch64-yoe-linux --datadir=/host-native/usr/share --sysconfdir=/host-native/etc --sharedstatedir=/host-native/com --localstatedir=/host-native/var --libdir=/host-native/usr/lib/aarch64-yoe-linux --includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include --infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-default-pie --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=aarch64-yoe-linux- --without-local-prefix --disable-install-libiberty --disable-libssp --enable-libitm --enable-lto --disable-bootstrap --with-system-zlib --with-linker-hash-style=sysv --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/13.2.0 --with-sysroot=/not/exist --with-build-sysroot=/host --enable-poison-system-directories=error --with-system-zlib --disable-static --disable-nls --with-glibc-version=2.28 --enable-initfini-array --enable-__cxa_atexit Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (GCC) COLLECT_GCC_OPTIONS='-mcpu=cortex-a72.cortex-a53' '-mbranch-protection=standard' '--sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-cortexa53-crypto-yoe-linux/glibc/2.38-r0/recipe-sysroot' '-fuse-ld=bfd' '-c' '-march=armv8.2-a+sve' '-v' '-mlittle-endian' '-mabi=lp64' /mnt/b/yoe/master/build/tmp/work/cortexa72-cortexa53-crypto-yoe-linux/glibc/2.38-r0/recipe-sysroot-native/usr/bin/aarch64-yoe-linux/../../libexec/aarch64-yoe-linux/gcc/aarch64-yoe-linux/13.2.0/as -v -EL -march=armv8.2-a+sve -march=armv8-a+crc -mabi=lp64 -o a.o a.s GNU assembler version 2.41.0 (aarch64-yoe-linux) using BFD version (GNU Binutils) 2.41.0.20230731 a.s: Assembler messages: a.s:2: Error: selected processor does not support `ptrue p0.b' However if I remove -mcpu=cortex-a72.cortex-a53 or change it to -mcpu=cortex-a72.cortex-a53+sve then it works ok. Interesting part is -march values in the assembler commandline order. as -v -EL -march=armv8.2-a+sve -march=armv8-a+crc -mabi=lp64 -o a.o a.s as we can see the -march computed from -mcpu is specified *after* the -march passed by user. is this a bug?
[Bug c++/108681] New: gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 Bug ID: 108681 Summary: gcc hangs compiling opencv/channels_combine.cpp for aarch64 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- GCC-trunk as of 31924665c86d47af6b1f22a74f594f2e1dc0ed2d is taking a long long time, probably a hang since I cancelled it after 12 mins ) compiling this file https://uclibc.org/~kraj/channels_combine.i aarch64-yoe-linux/aarch64-yoe-linux-g++ channels_combine.i -O2 ( hangs ) It compiled ok with -O0,-Os,-Og,-Oz but not with -O1,-O2,-O3
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #22 from Khem Raj --- (In reply to Jakub Jelinek from comment #20) > How could these changes result in > ../harfbuzz-6.0.0/src/hb-map.hh:295:5: error: no match for ‘operator|’ > (operand types are ‘hb_filter_iter_t unsigned int, true>::item_t>, bool (hb_hashmap_t true>::item_t::*)() const, const&, 0>’ and > ‘hb_reduce_t::hash() > const:: true>::item_t&)>, unsigned int>’) > errors? I can see that with a cross-compiler, so VRP miscompiling the C++ > FE is not an option. argh my bad, filled in wrong tab. Sorry about this.
[Bug c++/107461] [12 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #6 from Khem Raj --- This is now resulting in build error in harfbuzz on aarch64 which did not happen before, the testcase is here https://uclibc.org/~kraj/hb-aat-layout.cc.i Compile cmd used is /mnt/b/cross/aarch64-linux-musl/tools/bin/aarch64-linux-musl-g++ --sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Isrc/libharfbuzz.so.0.60600.0.p -Isrc -I../harfbuzz-6.0.0/src -I. -I../harfbuzz-6.0.0 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++11 -fno-rtti -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DHAVE_CONFIG_H -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot-native= -fvisibility-inlines-hidden -fPIC -pthread -Wno-non-virtual-dtor -MD -MQ src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -MF src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o.d -o src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -c ../harfbuzz-6.0.0/src/hb-aat-layout.cc
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #19 from Khem Raj --- This is now resulting in build error in harfbuzz on aarch64 which did not happen before, the testcase is here https://uclibc.org/~kraj/hb-aat-layout.cc.i Compile cmd used is /mnt/b/cross/aarch64-linux-musl/tools/bin/aarch64-linux-musl-g++ --sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot -fstack-protector-strong -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Isrc/libharfbuzz.so.0.60600.0.p -Isrc -I../harfbuzz-6.0.0/src -I. -I../harfbuzz-6.0.0 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++11 -fno-rtti -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -DHAVE_CONFIG_H -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/harfbuzz-6.0.0=/usr/src/debug/harfbuzz/6.0.0-r0 -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/build=/usr/src/debug/harfbuzz/6.0.0-r0 -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fmacro-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot= -fdebug-prefix-map=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/harfbuzz/6.0.0-r0/recipe-sysroot-native= -fvisibility-inlines-hidden -fPIC -pthread -Wno-non-virtual-dtor -MD -MQ src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -MF src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o.d -o src/libharfbuzz.so.0.60600.0.p/hb-aat-layout.cc.o -c ../harfbuzz-6.0.0/src/hb-aat-layout.cc
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 --- Comment #10 from Khem Raj --- (In reply to Andrew Pinski from comment #9) > (In reply to Andrew Pinski from comment #8) > > (In reply to Khem Raj from comment #7) > > > in Yocto we build outside the source tree. And during cross-build it will > > > copy aarch64.h into builddir and use it from there but then build can not > > > find files it includes since its being included from builddir. This patch > > > below helps > > > > aarch64.h is never copied into the builddir. > > Even for cross builds. > I think something else is wrong. Please file a different bug with the full > log? Including the part where the copy happens because I just did a: > find . -name aarch64.h > in the build directory of the cross build of GCC 12 I had around and there > was no such file happening. you are right. I should have mentioned that these copying is done by yocto builds for working though its notion of multilibs [1]. However, I think if we apply this fix it should not regress builds and we will have one less patch to carry in yocto. [1] https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/gcc/gcc-multilib-config.inc#n30
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #7 from Khem Raj ---
in Yocto we build outside the source tree. And during cross-build it will copy
aarch64.h into builddir and use it from there but then build can not find files
it includes since its being included from builddir. This patch below helps
Subject: [PATCH] aarch64: Fix include paths when S != B
aarch64.h gets copied into build directory when built out of tree, in
this case build uses this file but does not find the includes inside it
since they are not found in any of include paths specified in compiler
cmdline.
Fixes build errors like
% g++ -c
-isystem/mnt/b/yoe/master/build/tmp/work/x86_64-linux/gcc-cross-aarch64/13.0.1-r0/recipe-sysroot-native/usr/include
-O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc
-I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/build
-I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/../include
-I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/../libcpp/include
-o build/gencheck.o
../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/gencheck.cc
In file included from ./tm.h:34,
from
../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/gencheck.cc:23:
./config/aarch64/aarch64.h:164:10: fatal error: aarch64-option-extensions.def:
No such file or directory
164 | #include "aarch64-option-extensions.def"
| ^~~
compilation terminated.
Upstream-Status: Pending
Signed-off-by: Khem Raj
---
gcc/config/aarch64/aarch64.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 7129ed1ff37..3ca7068b4cb 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -161,8 +161,8 @@
enum class aarch64_feature : unsigned char {
#define AARCH64_OPT_EXTENSION(A, IDENT, C, D, E, F) IDENT,
#define AARCH64_ARCH(A, B, IDENT, D, E) IDENT,
-#include "aarch64-option-extensions.def"
-#include "aarch64-arches.def"
+#include "config/aarch64/aarch64-option-extensions.def"
+#include "config/aarch64/aarch64-arches.def"
};
/* Define unique flags for each of the above. */
@@ -171,8 +171,8 @@ enum class aarch64_feature : unsigned char {
= aarch64_feature_flags (1) << int (aarch64_feature::IDENT);
#define AARCH64_OPT_EXTENSION(A, IDENT, C, D, E, F) HANDLE (IDENT)
#define AARCH64_ARCH(A, B, IDENT, D, E) HANDLE (IDENT)
-#include "aarch64-option-extensions.def"
-#include "aarch64-arches.def"
+#include "config/aarch64/aarch64-option-extensions.def"
+#include "config/aarch64/aarch64-arches.def"
#undef HANDLE
#endif
[Bug target/105144] [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #6 from Khem Raj --- I am seeing a build failure which looks like a race condition to me. Perhaps related to this or related commits in this series. | g++ -c -isystem/mnt/b/yoe/master/build/tmp/work/x86_64-linux/gcc-cross-aarch64/13.0.1-r0/recipe-sysroot-native/usr/include -O2 -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc -I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/build -I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/../include -I../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/../libcpp/include \ | -o build/gencheck.o ../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/gencheck.cc | yes | checking for gethostbyname... yes | | checking for exported symbols... In file included from ./tm.h:34, | from ../../../../../../../work-shared/gcc-13.0.1-r0/gcc-b2ec2504af77b35e748067eeb846821d12a6b6b4/gcc/gencheck.cc:23: | ./config/aarch64/aarch64.h:164:10: fatal error: aarch64-option-extensions.def: No such file or directory | 164 | #include "aarch64-option-extensions.def" | | ^~~ | compilation terminated. | make[1]: *** [Makefile:2855: build/gencheck.o] Error 1 | make[1]: *** Waiting for unfinished jobs
[Bug c++/108564] New: RISCV std::atomic needs libatomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108564
Bug ID: 108564
Summary: RISCV std::atomic needs libatomics
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
following test generates a call to __atomic_exchange_1 with gcc trunk ( soon to
be gcc 13 ) if I use std::atomic that seems to not need libatomic but
std::atomic does need libatomic. Is that expected ?
#include
std::atomic _closed;
void test(void) {
_closed.exchange(true);
}
[Bug tree-optimization/105312] [11 Regression] ICE in gimple_expand_vec_cond_expr on arm-linux since r12-834-ga6eacbf1055520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312 --- Comment #8 from Khem Raj --- yeah I can verify that the ICE is gone.
[Bug middle-end/105316] Seemingly bogus -Wdangling-pointer from ppc/ppc64 kernel printk with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105316 --- Comment #2 from Khem Raj --- ah yes. Thanks
[Bug middle-end/105316] New: Seemingly bogus -Wdangling-pointer from ppc/ppc64 kernel printk with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105316
Bug ID: 105316
Summary: Seemingly bogus -Wdangling-pointer from ppc/ppc64
kernel printk with gcc12
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
I have reduced this case from ppc kernel 5.15, this breaks the kernel build as
the warning is treated as error.
ftrace.i
==
int _printk(const char *fmt, ...);
static void ftrace_modify_code() {
_printk("replaced (%s)", ({ char __str[sizeof(" ")]; __str;
}));
}
=
powerpc64le-yoe-linux-musl-gcc -c ftrace.i -Werror=dangling-pointer
ftrace.i: In function 'ftrace_modify_code':
ftrace.i:4:2: error: using a dangling pointer to '__str'
[-Werror=dangling-pointer=]
4 | _printk("replaced (%s)", ({ char __str[sizeof(" ")];
__str; }));
|
^~~
ftrace.i:4:35: note: '__str' declared here
4 | _printk("replaced (%s)", ({ char __str[sizeof(" ")];
__str; }));
| ^
cc1: some warnings being treated as errors
[Bug middle-end/105312] New: attribute__((optimize("-O3"))) stress_matrix_xy_identity compiling stress-ng for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312
Bug ID: 105312
Summary: attribute__((optimize("-O3")))
stress_matrix_xy_identity compiling stress-ng for arm
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
GCC 12 gets into an ICE when compiling this testcase (reduced from stress-ng)
typedef float stress_matrix_type_t;
typedef unsigned int size_t;
static void __attribute__((optimize("-O3"))) stress_matrix_xy_identity(
const size_t n,
stress_matrix_type_t a[restrict n][n],
stress_matrix_type_t b[restrict n][n],
stress_matrix_type_t r[restrict n][n])
{
register size_t i;
(void)a;
(void)b;
for (i = 0; i < n; i++) {
register size_t j;
for (j = 0; j < n; j++)
r[i][j] = (i == j) ? 1.0 : 0.0;
return;
}
}
===
arm-yoe-linux-musleabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a15
-fstack-protector-strong -D_FORTIFY_SOURCE=2 stress-matrix.i
during GIMPLE pass: isel
stress-matrix.i: In function 'stress_matrix_xy_identity':
stress-matrix.i:3:46: internal compiler error: in gimple_expand_vec_cond_expr,
at gimple-isel.cc:268
3 | static void __attribute__((optimize("-O3"))) stress_matrix_xy_identity(
| ^
0x15d4b28 internal_error(char const*, ...)
???:0
0x6005fb fancy_abort(char const*, int, char const*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #11 from Khem Raj --- yes thanks. I have done so https://jira.mongodb.org/browse/SERVER-65664
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251
--- Comment #9 from Khem Raj ---
how does something like this look ?
#include
#include
#include
#include
#ifdef __cpp_lib_hardware_interference_size
using std::hardware_constructive_interference_size;
using std::hardware_destructive_interference_size;
#else
// 64 bytes on x86-64 │ L1_CACHE_BYTES │ L1_CACHE_SHIFT │
__cacheline_aligned │ ...
constexpr std::size_t hardware_constructive_interference_size = 64;
constexpr std::size_t hardware_destructive_interference_size = 64;
#endif
class NetworkCounter {
private:
template
struct alignas(alignment) WithAlignment : T {
using T::T;
};
template
using WithAlignmentAtLeast = WithAlignment;
// These two counters are always incremented at the same time, so
// we place them on the same cache line.
template
using CacheAligned = WithAlignmentAtLeast;
struct Together {
long long logicalBytesIn{0};
long long requests{0};
};
CacheAligned _together{};
static_assert(sizeof(decltype(_together)) <=
hardware_destructive_interference_size,
"cache line spill");
};
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #8 from Khem Raj --- So in this case if I change static_assert(sizeof(decltype(_together)) <= hardware_constructive_interference_size, "cache line spill"); to static_assert(sizeof(decltype(_together)) <= hardware_destructive_interference_size, "cache line spill"); should set it right
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #6 from Khem Raj --- this is from mongodb.
[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #4 from Khem Raj --- I dont think its a bug per-se, I am looking for fixing it right way. Should I pass a non-default value via gcc cmdline or adjust the size expectations in code.
[Bug middle-end/105253] __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253 --- Comment #3 from Khem Raj --- (In reply to Andrew Pinski from comment #1) > Two things. First the error message is for arm target but you then reference > x86_64 target options. > > Second there is a loop for popcount which gets translated but that was > guarded by a check for optab for popcount existing but maybe that changed. yes the issue is seen on both arm and x86_64, So test case is from x86_64 but the error message is from arm build. I can reduce that too tomorrow. Its with -O2, I have a shell script in tarball which has all the options used to compile.
[Bug c/105253] New: __popcountdi2 calls generated in kernel code with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253 Bug ID: 105253 Summary: __popcountdi2 calls generated in kernel code with gcc12 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- Created attachment 52794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52794&action=edit test case gcc 12 when using -march=core2 generates __popcountdi2 calls which go unresolved in kernel and build fails. When I use -march=corei7 then the calls are optimized away. Interestingly, gcc-11 did not emit these calls even with -march=core2, a similar error is seen when compiling kernel for arm arm-yoe-linux-gnueabi-ld.bfd: arch/arm/probes/kprobes/actions-common.o: in function `simulate_ldm1stm1': actions-common.c:(.kprobes.text+0x74): undefined reference to `__popcountsi2' Attached testcase demonstrates the behaviour on x86_64. Is it expected behavior in gcc 12 ?
[Bug c++/105251] New: static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251
Bug ID: 105251
Summary: static assert sizeof(decltype(_together)) <=
hardware_constructive_interference_size fails with
gcc12
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
This testcase below fails to compile with gcc12 on aarch64 but works ok with
gcc11
gcc12
=
$ aarch64-yoe-linux-musl-g++
--sysroot=/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux-musl/mongodb/4.4.13-r0/recipe-sysroot
a.cpp -std=c++17
a.cpp:35:47: error: static assertion failed: cache line spill
35 | static_assert(sizeof(decltype(_together)) <=
hardware_constructive_interference_size,
|
^~
a.cpp:35:47: note: the comparison reduces to '(256 <= 64)'
=
a.cpp
=
#include
#include
#include
#include
#ifdef __cpp_lib_hardware_interference_size
using std::hardware_constructive_interference_size;
using std::hardware_destructive_interference_size;
#else
// 64 bytes on x86-64 │ L1_CACHE_BYTES │ L1_CACHE_SHIFT │
__cacheline_aligned │ ...
constexpr std::size_t hardware_constructive_interference_size = 64;
constexpr std::size_t hardware_destructive_interference_size = 64;
#endif
class NetworkCounter {
private:
template
struct alignas(alignment) WithAlignment : T {
using T::T;
};
template
using WithAlignmentAtLeast = WithAlignment;
// These two counters are always incremented at the same time, so
// we place them on the same cache line.
template
using CacheAligned = WithAlignmentAtLeast;
struct Together {
long long logicalBytesIn{0};
long long requests{0};
};
CacheAligned _together{};
static_assert(sizeof(decltype(_together)) <=
hardware_constructive_interference_size,
"cache line spill");
};
[Bug c++/105234] inlining failed in call to 'always_inline' 'memset': target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 --- Comment #3 from Khem Raj --- Second sample works when I do not use _FORTIFY_SOURCES=2, so perhaps gcc-12 needs to adjust some glibc headers ?
[Bug c++/105234] inlining failed in call to 'always_inline' 'fmt::v8::basic_format_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 --- Comment #2 from Khem Raj --- Created attachment 52787 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52787&action=edit test case 2
[Bug c++/105234] inlining failed in call to 'always_inline' 'fmt::v8::basic_format_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 --- Comment #1 from Khem Raj --- here is another testcase from gnupg on mips with gcc12 failing $ mips-yoe-linux-gcc dirmngr.i In file included from /mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/gnupg/2.3.4-r0/recipe-sysroot/usr/include/string.h:535, from ../../gnupg-2.3.4/dirmngr/dirmngr.c:29: /mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/gnupg/2.3.4-r0/recipe-sysroot/usr/include/bits/string_fortified.h: In function 'start_connection_thread': /mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux/gnupg/2.3.4-r0/recipe-sysroot/usr/include/bits/string_fortified.h:57:42: error: inlining failed in call to 'always_inline' 'memset': target specific option mismatch 57 | __NTH (memset (void *__dest, int __ch, size_t __len)) | ^~ ../../gnupg-2.3.4/dirmngr/dirmngr.c:2183:3: note: called from here 2183 | memset (&argval, 0, sizeof argval); | ^~
[Bug c++/105234] New: nlining failed in call to 'always_inline' 'fmt::v8::basic_format_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234
Bug ID: 105234
Summary: nlining failed in call to 'always_inline'
'fmt::v8::basic_format_string::basic_format_string(const S&)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
Created attachment 52786
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52786&action=edit
test case
Attached testcase fails to compile with gcc-12/mips but it works ok with gcc
11.2
$ mips-yoe-linux-musl-g++ -O0 AtomicFile.cpp.i
In file included from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/util/Tokenizer.hpp:23,
from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/Util.hpp:22,
from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/AtomicFile.cpp:22:
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/third_party/fmt/core.h:
In constructor 'core::Error::Error(T&& ...) [with T = {const char (&)[31],
const std::__cxx11::basic_string,
std::allocator >&, char*}]':
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/third_party/fmt/core.h:3057:41:
error: inlining failed in call to 'always_inline'
'fmt::v8::basic_format_string::basic_format_string(const S&) [with
S = char [31]; typename std::enable_if >::value, int>::type = 0; Char =
char; Args = {const std::__cxx11::basic_string,
std::allocator >&, char*}]': target specific option mismatch
3057 | FMT_CONSTEVAL FMT_INLINE basic_format_string(const S& s) : str_(s) {
| ^~~
In file included from
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/AtomicFile.cpp:25:
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/core/exceptions.hpp:57:52:
note: called from here
57 | : ErrorBase(fmt::format(std::forward(args)...))
|^
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/third_party/fmt/core.h:3117:45:
error: inlining failed in call to 'always_inline' 'std::string
fmt::v8::format(format_string, T&& ...) [with T = {const
std::__cxx11::basic_string, std::allocator
>&, char*}]': target specific option mismatch
3117 | FMT_NODISCARD FMT_INLINE auto format(format_string fmt, T&&...
args)
| ^~
/mnt/b/yoe/master/build/tmp/work/mips32r2-yoe-linux-musl/ccache/4.6-r0/ccache-4.6/src/core/exceptions.hpp:57:52:
note: called from here
57 | : ErrorBase(fmt::format(std::forward(args)...))
|^
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #8 from Khem Raj --- this change seems to cause a regression when build baremetal toolchain, it ends up generating /usr/lib/-gdb.py instead of libstdc++-gdb.py, the gcc tuple to build is arm-none-eabi the libstdc++.la looks like this # libstdc++.la - a libtool library file # Generated by libtool (GNU libtool 1.3134 2009-11-29) 2.2.7a # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libstdc++.a' # Linker flags that can not go in dependency_libs. inherited_linker_flags='' # Libraries that this one depends upon. dependency_libs=' -lm' # Names of additional weak libraries provided by this library weak_library_names='' # Version information for libstdc++. current=6 age=0 revision=29 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib'
[Bug analyzer/100011] internal compiler error in analyzer during IPA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100011 --- Comment #1 from Khem Raj --- this one seems to be the cause https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3a66c289a3f395e50de79424e1e6f401a4dc1ab7
[Bug analyzer/100011] New: internal compiler error in analyzer during IPA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100011
Bug ID: 100011
Summary: internal compiler error in analyzer during IPA pass
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
I am seeing a ICE in gcc when compiling attached reduced testcase from gnutls
project. This is caused by 3a66c289a3f395e50de79424e1e6f401a4dc1ab7
done for #99042, #99774
a.i
=
void terminate(int sig)
{
char buf[64] = { 0 };
exit(1);
}
int main(int argc, char **argv)
{
signal(0, terminate);
return 0;
}
=
$ /tmp/gcc/gcc/cc1 a.i -fanalyzer
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 884k} {heap 884k}
{heap 884k} {heap 884k} {heap 1076k}
{heap 1076k} {heap 1076k}Streaming LTO
during IPA pass: analyzer
a.i: At top level:
a.i:10:9: internal compiler error: Segmentation fault
10 | return 0;
| ^
0xdf96cf crash_signal
/home/kraj/work/gcc/gcc/toplev.c:327
0x11b4e06 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/home/kraj/work/gcc/gcc/analyzer/region-model.cc:729
0x195128a ana::diagnostic_manager::add_events_for_eedge(ana::path_builder
const&, ana::exploded_edge const&, ana::checker_path*) const
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1554
0x1951c04 ana::diagnostic_manager::build_emission_path(ana::path_builder
const&, ana::exploded_path const&, ana::checker_path*) const
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1183
0x1951dcb ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1128
0x195527f ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1051
0x1952250 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/home/kraj/work/gcc/gcc/analyzer/diagnostic-manager.cc:1100
0x119650c ana::impl_run_checkers(ana::logger*)
/home/kraj/work/gcc/gcc/analyzer/engine.cc:4887
0x11972dc ana::run_checkers()
/home/kraj/work/gcc/gcc/analyzer/engine.cc:4944
0x1189af8 execute
/home/kraj/work/gcc/gcc/analyzer/analyzer-pass.cc:87
[Bug target/99658] __divmoddi4 calls are generated on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99658 --- Comment #2 from Khem Raj --- (In reply to Richard Biener from comment #1) > Yes. GCC rightfully expects all libgcc functions to be available. Arguably > one divmod call is better than two calls to mod and div. thanks makes sense.
[Bug target/99658] New: __divmoddi4 calls are generated on i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99658
Bug ID: 99658
Summary: __divmoddi4 calls are generated on i686
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
Following is a reduced case from Virtualbox which fails to link because it
expects libgcc function __divmoddi4 which is not available in kernel modules,
gcc 10.x does not generate these calls but gcc 11 does.
void foo(unsigned char *u8Second, unsigned int *u32Nanosecond, long long
timeSpec)
{
long long i64Div;
int i32Div;
int i32Rem;
i64Div = timeSpec;
i32Rem = (int)(i64Div % 10);
i64Div /= 10;
*u32Nanosecond = i32Rem;
i32Rem = (int)(i64Div % 60);
*u8Second = i32Rem;
}
$ i686-yoe-linux-musl-gcc -O3 a.c -S -fverbose-asm
in a.s we see
...
call__divmoddi4@PLT #
movl%edx, %ebx #, divmod_tmp_12
movl%eax, %ecx # tmp163, divmod_tmp_12
...
but when compiled with gcc 10 it uses __moddi3 and __divdi3
is this expected?
[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489 --- Comment #10 from Khem Raj --- (In reply to Martin Sebor from comment #9) > Fixed in r11-7658. I validated the fix as well.
[Bug rtl-optimization/99581] New: internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 Bug ID: 99581 Summary: internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- Created attachment 50384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50384&action=edit testcase when building the attached source for ppc64 target GCC is ICE'ing $ powerpc64le-yoe-linux-musl-g++ a.cpp -O2 -c during RTL pass: final a.cpp: In member function 'void QTWTF::TCMalloc_PageHeap::scavengerThread()': a.cpp:15583:1: internal compiler error: in print_operand_address, at config/rs6000/rs6000.c:14082 15583 | } | ^ 0x1532d58 internal_error(char const*, ...) ???:0 0x5e46b7 fancy_abort(char const*, int, char const*) ???:0 0x991823 output_address(machine_mode, rtx_def*) ???:0 0x991771 output_operand(rtx_def*, int) ???:0 0x99241c output_asm_insn(char const*, rtx_def**) ???:0 0x996228 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ???:0
[Bug tree-optimization/99489] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489 Khem Raj changed: What|Removed |Added Known to work||10.2.0 Host||x86_64 Known to fail||11.0 Target||aarch64 Build||x86_64 --- Comment #1 from Khem Raj --- my compiler gcc version 11.0.1 20210308 (experimental) (GCC)
[Bug tree-optimization/99489] New: internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489 Bug ID: 99489 Summary: internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name() Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- Created attachment 50339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50339&action=edit testcase Attached test is causing ICE on aarch64 targets aarch64-yoe-linux-musl-gcc -O2 -c dlt_offline_logstorage_behavior.i during GIMPLE pass: strlen /mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux-musl/dlt-daemon/2.18.6-r0/git/src/offlinelogstorage/dlt_offline_logstorage_behavior.c: In function 'dlt_logstorage_log_file_name.part.0': /mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux-musl/dlt-daemon/2.18.6-r0/git/src/offlinelogstorage/dlt_offline_logstorage_behavior.c:54:6: internal compiler error: Segmentation fault 54 | void dlt_logstorage_log_file_name(char *log_file_name, | ^~~~ 0x1669eb8 internal_error(char const*, ...) ???:0 0x679c22 private_lookup_attribute(char const*, unsigned long, tree_node*) ???:0 0x77a73f gimple_call_alloc_size(gimple*, generic_wide_int*, range_query*) ???:0 0xd65005 strlen_dom_walker::before_dom_children(basic_block_def*) ???:0 0x14e02f7 dom_walker::walk(basic_block_def*) ???:0
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #16 from Khem Raj --- the kernel build failures still happen. I am re-opened #99454 and #99455
[Bug c/99455] internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455 --- Comment #3 from Khem Raj --- Created attachment 50333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50333&action=edit testcase
[Bug c/99455] internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455 Khem Raj changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Khem Raj --- This is still reproducing with gcc built after fix for #99422 went in.
[Bug c/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 Khem Raj changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from Khem Raj --- This is not resolved with the fix for #99422 therefore I am re-opening. I tried with fresh build with head being https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d9a70ea3881c284b7689b691d54d047b55b486d which includes the fix for #99422
[Bug target/99437] [11 Regression] Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99437 Khem Raj changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Khem Raj --- I can confirm that the above commit fixed the ICE
[Bug c/99455] New: internal compiler error: In function 'prb_reserve_in_last' in linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99455
Bug ID: 99455
Summary: internal compiler error: In function
'prb_reserve_in_last' in linux kernel
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
compiling attached source with -Os causes the ICE, it works ok with -O1 or -O2
=
$ x86_64-yoe-linux-musl-gcc -Os b.c -c
b.c:21245:1: error: unrecognizable insn:
21245 | }
| ^
(insn 58 57 446 6 (parallel [
(asm_operands/v ("push %0 ; popf") ("") 0 [
(mem:DI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [27 %sfp+-72 S8 A64])
(const_int 8 [0x8])) [16 e_56(D)->irqflags+0 S8
A64])
]
[
(asm_input:DI ("g") b.c:9370)
]
[] b.c:9370)
(clobber (mem:BLK (scratch) [0 A8]))
(clobber (reg:CC 17 flags))
]) "b.c":9370:2 -1
(nil))
during RTL pass: postreload
b.c:21245:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x1564e08 internal_error(char const*, ...)
???:0
0x60277f fancy_abort(char const*, int, char const*)
???:0
0x5dddbe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x5a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
==
gcc version 11.0.1 20210307 (experimental) (GCC)
[Bug c/99454] internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454 --- Comment #1 from Khem Raj --- btw. another data point when compiling with -Os it works but fails with -O1 or -O2 it was working ok with gcc snapshot from 10 days ago.
[Bug c/99454] New: internal compiler error: kernel module tg3 tg3_start_xmit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454
Bug ID: 99454
Summary: internal compiler error: kernel module tg3
tg3_start_xmit
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
Created attachment 50325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50325&action=edit
testcase
Compiling kernel 5.10 for x86_64 is resulting in below ICE
===
$ x86_64-yoe-linux-musl/x86_64-yoe-linux-musl-gcc -c a.c -O
a.c: In function 'tg3_start_xmit':
a.c:97234:1: error: unrecognizable insn:
97234 | }
| ^
(insn 258 1293 1351 23 (parallel [
(set (reg:SI 0 ax [orig:542 sum ] [542])
(asm_operands:SI (" addl %1, %0
adcl %2, %0
adcl %3, %0
adcl $0, %0
") ("=r") 0 [
(mem:SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 64 [0x40])) [555 %sfp+-32 S8
A64])
(const_int 16 [0x10])) [4 MEM[(struct iphdr
*)_287].daddr+0 S4 A32])
(mem:SI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 64 [0x40])) [555 %sfp+-32 S8
A64])
(const_int 12 [0xc])) [4 MEM[(struct iphdr
*)_287].saddr+0 S4 A32])
(const_int 1536 [0x600])
(reg:SI 0 ax [orig:542 sum ] [542])
]
[
(asm_input:SI ("g") a.c:48913)
(asm_input:SI ("g") a.c:48913)
(asm_input:SI ("g") a.c:48913)
(asm_input:SI ("0") a.c:48913)
]
[] a.c:48913))
(clobber (reg:CC 17 flags))
]) "a.c":48913:2 -1
(nil))
during RTL pass: postreload
a.c:97234:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x1564e08 internal_error(char const*, ...)
???:0
0x60277f fancy_abort(char const*, int, char const*)
???:0
0x5dddbe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x5a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
===
attached is the preprocessed source
compiler version
gcc version 11.0.1 20210307 (experimental) (GCC)
[Bug target/99437] Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99437 --- Comment #1 from Khem Raj --- the version of gcc in use is gcc version 11.0.1 20210306 (experimental) (GCC)
[Bug target/99437] New: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99437 Bug ID: 99437 Summary: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15' Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- Created attachment 50321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50321&action=edit test case gcc 11 fails to build openCV for aarch64 due to an assembler error on attached sample program. % arch64-yoe-linux-g++ -c a.cpp -O /tmp/ccxRnB71.s: Assembler messages: /tmp/ccxRnB71.s:113: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,15' /tmp/ccxRnB71.s:249: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,14' /tmp/ccxRnB71.s:385: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,13' /tmp/ccxRnB71.s:521: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,12' /tmp/ccxRnB71.s:657: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,11' /tmp/ccxRnB71.s:793: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,10' /tmp/ccxRnB71.s:929: Error: immediate value out of range 1 to 8 at operand 3 -- `shrn v1.8b,v1.8h,9'
[Bug c/99420] New: New warning -Warray-parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420
Bug ID: 99420
Summary: New warning -Warray-parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
Following code (reduced from nss ) exhibits new warning with gcc11 on x86_64,
this doe s not happen when both these externs are in one function e.g. foo(),
its an expansion of PR_STATIC_ASSERT from nspr headers
#define PR_STATIC_ASSERT(condition) \
extern void pr_static_assert(int arg[(condition) ? 1 : -1])
my gcc version is
gcc version 11.0.1 20210303 (experimental) (GCC)
a.c
==
void foo()
{
unsigned char bytes[(440 / 8) * 2];
extern void pr_static_assert(int arg[(sizeof(bytes) >= 32) ? 1 : -1]);
}
void bar()
{
extern void pr_static_assert(int arg[(((long unsigned int)-1) > (long
unsigned int)1) ? 1 : -1]);
}
===
$ x86_64-yoe-linux-musl-gcc -c a.c -Werror=array-parameter=2
a.c: In function 'bar':
a.c:8:38: error: argument 1 of type 'int[1]' with mismatched bound
[-Werror=array-parameter=]
8 | extern void pr_static_assert(int arg[(((long unsigned int)-1) >
(long unsigned int)1) ? 1 : -1]);
|
^~
a.c:4:38: note: previously declared as 'int *'
4 | extern void pr_static_assert(int arg[(sizeof(bytes) >= 32) ? 1 :
-1]);
|
^~~
cc1: some warnings being treated as errors
[Bug c++/99354] New: spurious Wuninitialized warning diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99354
Bug ID: 99354
Summary: spurious Wuninitialized warning diagnostic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: raj.khem at gmail dot com
Target Milestone: ---
below test file triggers a warning with gcc 11, this worked fine with gcc10
=
float HexFloat16ToFloat(const unsigned char* value) {
unsigned int sign = (static_cast(value[1]) & 0x80) << 24U;
unsigned int exponent = (((static_cast(value[1]) & 0x7c) >> 2U)
+ 112U)
<< 23U;
unsigned int mantissa = ((static_cast(value[1]) & 0x3) << 8U |
static_cast(value[0]))
<< 13U;
unsigned int hex = sign | exponent | mantissa;
float* hex_float = reinterpret_cast(&hex);
return *hex_float;
}
g++ -O2 a.cpp -c -Wall
a.cpp: In function 'float HexFloat16ToFloat(const unsigned char*)':
a.cpp:11:11: warning: 'hex' is used uninitialized [-Wuninitialized]
11 | return *hex_float;
| ^
a.cpp:9:16: note: 'hex' declared here
9 | unsigned int hex = sign | exponent | mantissa;
|^~~
===
gcc is configured as below
Using built-in specs.
COLLECT_GCC=/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/opengl-es-cts/3.2.6.1-r0/recipe-sysroot-native/usr/bin/riscv64-yoe-linux/riscv64-yoe-linux-g++
COLLECT_LTO_WRAPPER=/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/opengl-es-cts/3.2.6.1-r0/recipe-sysroot-native/usr/bin/riscv64-yoe-linux/../../libexec/riscv64-yoe-linux/gcc/riscv64-yoe-linux/11.0.1/lto-wrapper
Target: riscv64-yoe-linux
Configured with:
../../../../../../work-shared/gcc-11.0.1-r0/gcc-7c657339d6a4a671b4cd8bc62ba4e0df6bfc7c72/configure
--build=x86_64-linux --host=x86_64-linux --target=riscv64-yoe-linux
--prefix=/host-native/usr --exec_prefix=/host-native/usr
--bindir=/host-native/usr/bin/riscv64-yoe-linux
--sbindir=/host-native/usr/bin/riscv64-yoe-linux
--libexecdir=/host-native/usr/libexec/riscv64-yoe-linux
--datadir=/host-native/usr/share --sysconfdir=/host-native/etc
--sharedstatedir=/host-native/com --localstatedir=/host-native/var
--libdir=/host-native/usr/lib/riscv64-yoe-linux
--includedir=/host-native/usr/include --oldincludedir=/host-native/usr/include
--infodir=/host-native/usr/share/info --mandir=/host-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/host-native --enable-clocale=generic --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-default-pie --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=riscv64-yoe-linux-
--without-local-prefix --disable-install-libiberty --disable-libssp
--enable-libitm --enable-lto --disable-bootstrap --with-system-zlib
--with-linker-hash-style=sysv --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/11.0.1
--with-sysroot=/not/exist --with-build-sysroot=/host
--enable-poison-system-directories --with-system-zlib --disable-static
--disable-nls --with-glibc-version=2.28 --enable-initfini-array
--enable-__cxa_atexit
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210226 (experimental) (GCC)
