[Bug sanitizer/113214] false-positive -Wstringop-overflow warning with thread sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214 --- Comment #2 from Arnd Bergmann --- The warning is now turned off in the kernel as a workaround: https://lore.kernel.org/all/CAHk-=whzbdlc024nxgjesfoopj9bo2bkuxhxr4h5wosyk9a...@mail.gmail.com/ Also, my local one-line workaround is applied for this driver, but this workaound is clearly not useful as a general solution: https://lore.kernel.org/lkml/sbbfz5zzdjj7hjcmyqvof3roe6zb43kflgmweopfu65hllxdep@m4pxjiuqxood/#t
[Bug sanitizer/113214] New: false-positive -Wstringop-overflow warning with thread sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214
Bug ID: 113214
Summary: false-positive -Wstringop-overflow warning with thread
sanitizer
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
I came across another -Wstringop-overflow warning while building the kernel in
a newly added device driver, when the thread sanitizer is enabled. Reduced my
test case to
void _dev_warn(const void *dev, ...);
struct xe_uc {
int guc;
};
struct xe_gt {
struct xe_tile *tile;
struct pf_queue {
unsigned int data[128];
unsigned int tail;
} pf_queue[4];
struct xe_uc uc;
};
#define container_of(ptr, type, member) ({ \
void *__mptr = (void *)(ptr); \
((type *)(__mptr - __builtin_offsetof(type, member))); })
void xe_guc_pagefault_handler(struct xe_uc *uc, int asid, void *msg, int len)
{
struct xe_gt *gt = container_of(uc, struct xe_gt, uc);
void *xe = gt->tile;
struct pf_queue *pf_queue;
if (len != 4)
return;
pf_queue = >pf_queue[asid % 4];
__builtin_memcpy(pf_queue->data + pf_queue->tail,
msg, len * sizeof(unsigned int));
_dev_warn(xe);
}
Original source code at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/xe/xe_gt_pagefault.c?h=next-20240103#n322
Reproducer at https://godbolt.org/z/MMaz8rqcj
aarch64-linux-gcc-13.2 -Wall -O2 -fsanitize=thread -Werror=stringop-overflow
-Wall -c xe_gt_pagefault.c
xe_gt_pagefault.c: In function 'xe_guc_pagefault_handler':
xe_gt_pagefault.c:26:9: error: writing 16 bytes into a region of size 0
[-Werror=stringop-overflow=]
26 | __builtin_memcpy(pf_queue->data + pf_queue->tail,
| ^
27 | msg, len * sizeof(unsigned int));
|
xe_gt_pagefault.c:6:25: note: at offset 8 into destination object 'tile' of
size 8
6 | struct xe_tile *tile;
| ^~~~
cc1: some warnings being treated as errors
Currently I see this with gcc-13.x and gcc-14.0 but not gcc-12.
[Bug tree-optimization/108402] False positive Wuninitialized with ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402 Arnd Bergmann changed: What|Removed |Added CC||arnd at linaro dot org --- Comment #7 from Arnd Bergmann --- I ran into a probably related issue and opened bug #110743 for it, with a reduced test case. I also found another variation in bug #104550, but that testcase was fixed by the referenced commit.
[Bug c/110743] New: Unexpected -ftrivial-auto-var-init=pattern behavior with partial bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110743
Bug ID: 110743
Summary: Unexpected -ftrivial-auto-var-init=pattern behavior
with partial bitfields
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
A warning showed up in Linux kernel builds with code that has a data structure
with sub-byte holes in it, making it appear as though the structure was
uninitialized even though there is no user before the intialization:
struct spi_mem_op {
struct {
int a : 1;
};
struct {
char b : 1;
long c;
};
};
void spi_nor_read_any_reg(struct spi_mem_op *);
void s25fs256t_post_bfpt_fixup_nor(void) {
struct spi_mem_op op;
spi_nor_read_any_reg();
}
$ x86_64-linux-gnu-gcc-12 -O2 -ftrivial-auto-var-init=pattern -Wuninitialized
x86-64 gcc 12.3 (Editor #1)
x86-64 gcc 12.3 - 905ms (5966B) ~392 lines filtered
Output of x86-64 gcc 12.3 (Compiler #1)
: In function 's25fs256t_post_bfpt_fixup_nor':
:12:21: warning: 'op' is used uninitialized [-Wuninitialized]
12 | struct spi_mem_op op;
| ^~
:12:21: note: 'op' declared here
12 | struct spi_mem_op op;
| ^~
See also https://godbolt.org/z/o96GfTaaT
gcc-11 and earlier don't show this behavior because they do not support
-ftrivial-auto-var-init=pattern. I notice that in the example above, the first
16 bytes of the structure are intialized to zero with an x86 SSE instruction
since they do not contain any actual data bytes, just single bits.
This seems to be the same underlying problem as in bug #104550, but that one is
marked fixed and I cannot reproduce it on gcc-12 or gcc-13.
[Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074 Bug ID: 110074 Summary: code bloat with -fprofile-args + -fsanitize=bounds Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: arnd at linaro dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 55231 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55231=edit simplified standalone version of linux kernel twofish cipher I noticed warnings about excessive stack usage in the Linux kernel in multiple files when both UBSAN and GCOV are enabled: crypto/twofish_common.c:683:1: error: the frame size of 2040 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] drivers/media/platform/mediatek/vcodec/vdec/vdec_vp9_req_lat_if.c:1589:1: error: the frame size of 1696 bytes is larger than 1400 bytes [-Werror=frame-larger-than=] drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c:754:1: error: the frame size of 1260 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] drivers/staging/media/rkvdec/rkvdec-vp9.c:1042:1: error: the frame size of 2176 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] This shows up across architectures in certain kernel configurations, but I have managed to come up with a simplified testcase based on the twofish cipher that lets me reproduce this in all gcc versions I tried (gcc-5.5 through 13.1): $ gcc-13 -O2 -Wframe-larger-than=100 -fprofile-arcs -fsanitize=bounds -fsanitize=thread -c twofish.c twofish.c: In function ‘__twofish_setkey’: twofish.c:662:1: warning: the frame size of 2320 bytes is larger than 100 bytes [-Wframe-larger-than=] Removing either the -fprofile-arcs or the -fsanitize=bounds option avoids this and produces more readable code. See https://godbolt.org/z/zvf7YqK5K for a demonstration using the attached testcase. Nick Desaulniers pointed out a recent change to LLVM that addresses a similar problem by not trying to sanitize code that was generated by gcov, see https://reviews.llvm.org/D150460
[Bug libgcc/108433] New: canadian cross aarch64/x86_64/aarch64 fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108433 Bug ID: 108433 Summary: canadian cross aarch64/x86_64/aarch64 fails to build Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: arnd at linaro dot org Target Milestone: --- I tried to build a set of cross compilers for all target architectures. Build architecture is arm64, host architecture is x86_64 or ppc64le, both of them fail the same way: cc -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fPIC -I. -I. -I../.././gcc -I/home/arnd/git/gcc/libgcc -I/home/arnd/git/gcc/libgcc/. -I/home/arnd/git/gcc/libgcc/../gcc -I/home/arnd/git/gcc/libgcc/../include -DHAVE_CC_TLS -o unwind-dw2-fde-dip.o -MT unwind-dw2-fde-dip.o -MD -MP -MF unwind-dw2-fde-dip.dep -fexceptions -c /home/arnd/git/gcc/libgcc/unwind-dw2-fde-dip.c -fvisibility=hidden -DHIDE_EXPORTS libgcc/unwind-dw2.c:967:20: error: ‘__LIBGCC_DWARF_CIE_DATA_ALIGNMENT__’ undeclared (first use in this function); did you mean ‘DWARF_CIE_DATA_ALIGNMENT’? The problem seems to be caused by configure picking up /usr/bin/cc as the compiler for building libgcc when in a canadian cross with build==target, despite another aarch64-linux-gnu-gcc being provided for this purpose: Configuring in aarch64-linux/libgcc configure: creating cache ./config.cache checking build system type... aarch64-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... mawk checking for aarch64-linux-ar... /home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/ar checking for aarch64-linux-lipo... lipo checking for aarch64-linux-nm... /home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/nm checking for aarch64-linux-ranlib... /home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/ranlib checking for aarch64-linux-strip... /home/arnd/cross/arm64/gcc-13.0.1-nolibc/aarch64-linux/lib/gcc/aarch64-linux/13.0.1/../../../../aarch64-linux/bin/strip checking whether ln -s works... yes checking for aarch64-linux-gcc... cc I think libgcc should either be built with the other compiler, or it should avoid dependencies on the having a matching target compiler version in the definition of __LIBGCC_DWARF_CIE_DATA_ALIGNMENT__.
[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930 Arnd Bergmann changed: What|Removed |Added CC||arnd at linaro dot org --- Comment #19 from Arnd Bergmann --- I checked the other target architectures that are supported by the kernel to see if anything else is affected. Apparently only sparc32 has a similar issue with a frame size of 2280 bytes using gcc-10 or higher, compared to 600 to 800 bytes for gcc-4 through gcc-9.
[Bug c/104711] New: Unnecessary -Wshift-negative-value warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711 Bug ID: 104711 Summary: Unnecessary -Wshift-negative-value warning Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: arnd at linaro dot org Target Milestone: --- During the discussion of increasing the C standard version of the Linux kernel fro m gnu89 to gnu99 or higher, it turned out that gcc warns about code that shifts negative signed integers [2]. This is undefined behavior in standard C99, but defined as a GNU extension in GCC.[3]. This warning is enabled by default at the -Wextra level for C99/GNU99 or higher, but disabled for C89/GNU89. In clang, the warning is enabled by default at the -Wall level but in turn disabled when building with -fwrapv or -fno-strict-overflow (as the Linux kernel does). It would be nice if future compiler releases could either demote the warning from being enabled at -Wextra to -Wpedantic, or follow clang and disable it when used with -fwrapv/-fno-strict-overflow. [1] https://lore.kernel.org/lkml/20220227010956.gw...@gate.crashing.org/ [2] https://www.godbolt.org/z/s1TzxrGz4 [3] https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Integers-implementation.html
[Bug middle-end/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
--- Comment #27 from Arnd Bergmann ---
The linux kernel instance from arch/parisc/ looks like a bug we fixed in
arch/arm a few years ago, by adding the required alignment directive to the
linker script.
If changing the linker script is not possible because of boot loader
requirements, then this should do as well:
diff --git a/arch/parisc/boot/compressed/misc.c
b/arch/parisc/boot/compressed/misc.c
index 2d395998f524..b91d6cf80c06 100644
--- a/arch/parisc/boot/compressed/misc.c
+++ b/arch/parisc/boot/compressed/misc.c
@@ -26,7 +26,7 @@
extern char input_data[];
extern int input_len;
/* output_len is inserted by the linker possibly at an unaligned address */
-extern __le32 output_len __aligned(1);
+extern struct { __u8 bytes; } output_len;
extern char _text, _end;
extern char _bss, _ebss;
extern char _startcode_end;
[Bug tree-optimization/102162] Byte-wise access optimized away at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
Arnd Bergmann changed:
What|Removed |Added
CC||arnd at linaro dot org
--- Comment #2 from Arnd Bergmann ---
I tried reproducing the issue with my original kernel code, using this input:
typedef unsigned u32;
#define __packed __attribute__((packed))
#define __get_unaligned_t(type, ptr) ({
\
const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr);
\
__pptr->x;
\
})
#define get_unaligned(ptr) __get_unaligned_t(typeof(*(ptr)), (ptr))
int f_unaligned(u32 *p)
{
return get_unaligned(p);
}
int g(u32 *p)
{
return *(p);
}
and it looks like I get correct output:
hppa64-linux-gcc -S kernel/test_unaligned.c -o - -O2
.LEVEL 2.0w
.text
.align 8
.globl f_unaligned
.type f_unaligned, @function
f_unaligned:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
ldb 0(%r26),%r20
ldb 1(%r26),%r19
depd,z %r20,39,40,%r20
depd,z %r19,47,48,%r19
ldb 2(%r26),%r31
ldb 3(%r26),%r28
or %r19,%r20,%r19
depd,z %r31,55,56,%r31
or %r31,%r19,%r31
or %r28,%r31,%r28
bve (%r2)
extrd,s %r28,63,32,%r28
.EXIT
.PROCEND
.size f_unaligned, .-f_unaligned
.align 8
.globl g
.type g, @function
g:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
ldw 0(%r26),%r28
bve (%r2)
extrd,s %r28,63,32,%r28
.EXIT
.PROCEND
.size g, .-g
.ident "GCC: (GNU) 11.1.0"
Any idea what the difference is between the working version and your broken
one?
[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673 --- Comment #4 from Arnd Bergmann --- I posted a set of kernel patches to address all the warnings I found at https://lore.kernel.org/lkml/20210322160253.4032422-1-a...@kernel.org/T/#t
[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673 --- Comment #2 from Arnd Bergmann --- Thank you for the detailed analysis. This was the last such warning I get with linux kernel randconfig build that I could not explain based on the earlier discussion, so now I can submit the local workarounds and reference the bug reports. Among the ten -Wstringop-overread warnings I got for this codebase, around half should not have been a warning, the others are mostly harmless, though the warning seems reasonable, while one or two seem to be actual bugs but need to be confirmed. Based on your explanation, is it safe to assume this can only affect the diagnostic output and not lead to incorrect or misoptimized code being generated?
[Bug sanitizer/99673] New: [11 Regression] bogus -Wstringop-overread warning with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
Bug ID: 99673
Summary: [11 Regression] bogus -Wstringop-overread warning with
address sanitizer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 50435
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50435=edit
manually reduced test case
gcc-11 warns about one file in the linux kernel, in which it fails to find the
size of an object:
$ arm-linux-gnueabi-gcc -Os -fno-inline-functions-called-once
-fsanitize=address
In function ‘ath11k_peer_assoc_h_vht’,
inlined from ‘ath11k_peer_assoc_prepare’ at
drivers/net/wireless/ath/ath11k/mac.c:92:2:
drivers/net/wireless/ath/ath11k/mac.c:66:13: warning:
‘ath11k_peer_assoc_h_vht_masked’ reading 16 bytes from a region of size 4
[-Wstringop-overread]
66 | if (ath11k_peer_assoc_h_vht_masked(vht_mcs_mask))
| ^~~~
drivers/net/wireless/ath/ath11k/mac.c: In function ‘ath11k_peer_assoc_prepare’:
drivers/net/wireless/ath/ath11k/mac.c:66:13: note: referencing argument 1 of
type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/net/wireless/ath/ath11k/mac.c:49:1: note: in a call to function
‘ath11k_peer_assoc_h_vht_masked’
49 | ath11k_peer_assoc_h_vht_masked(const u16
vht_mcs_mask[NL80211_VHT_NSS_MAX])
| ^~
I can't see where the '4' even comes from here, both in the original test case
and the reduced version
https://godbolt.org/z/79GE8M
$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (GCC) 11.0.1 20210315 (experimental)
The behavior seems to be target independent, I can reproduce it on arm and x86.
[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92860 Bug 92860 depends on bug 99592, which changed state. Bug 99592 Summary: arm: internal compiler error using arm_neon.h with -pg https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592 What|Removed |Added Status|RESOLVED|WAITING Resolution|FIXED |---
[Bug target/99592] arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592 Arnd Bergmann changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|FIXED |--- --- Comment #11 from Arnd Bergmann --- Thanks a lot!
[Bug target/99592] arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592 --- Comment #6 from Arnd Bergmann --- Created attachment 50395 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50395=edit preprocessed /usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h I've changed from the Ubuntu gcc-11 snapshot to a self-built one in the meantime, but in this version I had to pass the specific CPU type that was implied by the Ubuntu armhf version. arm-linux-gnueabihf-gcc-11 -pg -march=armv7-a -mfpu=vfpv3-d16 -O2 -mfloat-abi=hard -c /tmp/armcrash.i In file included from : /usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:71:9: internal compiler error: ‘global_options’ are modified in local context 71 | #pragma GCC pop_options | ^~~ 0xcf6aa3 cl_optimization_compare(gcc_options*, gcc_options*) /build/gcc-11-cross-76rIbd/gcc-11-cross-3ubuntu1/gcc/build/gcc/options-save.c:12589 0x8b031d handle_pragma_pop_options ../../src/gcc/c-family/c-pragma.c:1092 0x822501 c_parser_pragma ../../src/gcc/c/c-parser.c:12519 0x84e065 c_parser_external_declaration ../../src/gcc/c/c-parser.c:1758 0x84e811 c_parser_translation_unit ../../src/gcc/c/c-parser.c:1650 0x84e811 c_parse_file() ../../src/gcc/c/c-parser.c:21984 0x8ade35 c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1218
[Bug target/99600] [11 regression] out of memory for simple test case (x86 -march=atom) since r11-7274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99600 --- Comment #9 from Arnd Bergmann --- I now built gcc with and without the patch from attachment 50390 to find more broken kernel configurations and verify that they are all fixed. So far, all the broken configurations are fixed by the patch, I'll leave it running over night to see if something comes up. Thanks a lot for coming up with a patch so quickly!
[Bug target/99592] arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592 --- Comment #4 from Arnd Bergmann --- $ arm-linux-gnueabihf-gcc-11 -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabihf-gcc-11 COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/11/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11-20210310-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --without-target-system-zlib --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210310 (experimental) [master revision 8dc225d311e:2453ef06221:5987d8a79cda1069c774e5c302d5597310270026] (Ubuntu 11-20210310-1ubuntu1)
[Bug target/99592] arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592 Arnd Bergmann changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #2 from Arnd Bergmann --- (In reply to Martin Liška from comment #1) > Please, how do you configure the cross compiler? This is the Ubuntu snapshot build, Matthias Klose probably has the exact configuration at hand.
[Bug target/99600] [11 regression] out of memory for simple test case (x86 -march=atom)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99600 Arnd Bergmann changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #2 from Arnd Bergmann --- perf shows these functions as the most commonly called ones, presumably it's looping through all of those: 5.39% cc1 cc1[.] df_ref_create_structure 5.33% cc1 cc1[.] df_uses_record 4.41% cc1 cc1[.] ggc_internal_alloc 3.41% cc1 cc1[.] df_ref_record 2.79% cc1 cc1[.] peephole2_insns 2.69% cc1 cc1[.] ix86_lea_outperforms 2.58% cc1 cc1[.] df_insn_rescan 2.33% cc1 cc1[.] df_sort_and_compress_refs 2.05% cc1 cc1[.] df_free_ref This recent change touches ix86_lea_outperforms, could be related: https://github.com/gcc-mirror/gcc/commit/decd8fb01288
[Bug target/99600] [11 regression] out of memory for simple test case (x86 -march=atom)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99600 --- Comment #1 from Arnd Bergmann --- https://godbolt.org/z/z7h7r3
[Bug target/99600] New: [11 regression] out of memory for simple test case (x86 -march=atom)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99600
Bug ID: 99600
Summary: [11 regression] out of memory for simple test case
(x86 -march=atom)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Testing random Linux kernel builds with gcc-11 killed my box before I had a
reasonable "ulimit -d" limit set when it filled up 384GB of memory.
I have now set a limit and managed to produce a small test case:
$ ulimit -S -d 100 # one gigabyte
$ gcc-11 -O2 -march=atom test.c
virtual memory exhausted: Cannot allocate memory
$ cat test.c
char a;
char b;
long c;
long d() {
if (a )
c = b == 1 ? 1 << 3 : 1 << 2;
else
c = 0;
return 0 ;
}
$ gcc-11 --version
gcc-11 (Ubuntu 11-20210310-1ubuntu1) 11.0.1 20210310 (experimental) [master
revision 8dc225d311e:2453ef06221:5987d8a79cda1069c774e5c302d5597310270026]
[Bug target/99596] New: arm: internal error in single_pred_edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99596
Bug ID: 99596
Summary: arm: internal error in single_pred_edge
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I ran into this internal compiler error while building the Linux kernel in
random configurations, made a reduced test case:
$ arm-linux-gnueabihf-gcc-11 -Os -mtune=xscale -c cfi_cmdset_0002.c
during RTL pass: fwprop2
cfi_cmdset_0002.c: In function ‘i’:
cfi_cmdset_0002.c:16:1: internal compiler error: in single_pred_edge, at
basic-block.h:350
16 | }
| ^
0x7bf679 single_pred_edge
../../src/gcc/basic-block.h:350
0x7bf679 single_pred
../../src/gcc/basic-block.h:369
0x7bf679 rtl_ssa::function_info::create_degenerate_phi(rtl_ssa::ebb_info*,
rtl_ssa::set_info*)
../../src/gcc/rtl-ssa/blocks.cc:535
0x1860f6d rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:508
0x18617c3
rtl_ssa::function_info::change_insns(array_slice)
../../src/gcc/rtl-ssa/changes.cc:659
0x1862078 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:717
0x172f1cd try_fwprop_subst_pattern
../../src/gcc/fwprop.c:552
0x172f1cd try_fwprop_subst
../../src/gcc/fwprop.c:625
0x172f73e forward_propagate_and_simplify
../../src/gcc/fwprop.c:823
0x172f73e forward_propagate_into
../../src/gcc/fwprop.c:883
0x172fb8a forward_propagate_into
../../src/gcc/fwprop.c:835
0x172fb8a fwprop_insn
../../src/gcc/fwprop.c:954
0x172fc49 fwprop
../../src/gcc/fwprop.c:992
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
$ cat cfi_cmdset_0002.c
register int a asm("sp");
extern int b;
typedef struct {
long c[16 * 8 / 32];
} d;
int e;
int f;
int g;
d h;
int j(int, int, int, d);
int i(void) {
for (;;) {
b &(e, f, g, h);
j(e, f, g, h);
}
}
$ arm-linux-gnueabihf-gcc-11 --version
arm-linux-gnueabihf-gcc-11 (Ubuntu 11-20210310-1ubuntu1) 11.0.1 20210310
(experimental) [master revision
8dc225d311e:2453ef06221:5987d8a79cda1069c774e5c302d5597310270026]
[Bug target/99592] New: arm: internal compiler error using arm_neon.h with -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99592 Bug ID: 99592 Summary: arm: internal compiler error using arm_neon.h with -pg Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: arnd at linaro dot org Target Milestone: --- Including the arm_neon header fails when building with the 'pg' option $ arm-linux-gnueabihf-gcc-11 --version arm-linux-gnueabihf-gcc-11 (Ubuntu 11-20210310-1ubuntu1) 11.0.1 20210310 (experimental) [master revision 8dc225d311e:2453ef06221:5987d8a79cda1069c774e5c302d5597310270026] $ arm-linux-gnueabihf-gcc-11 -pg -O2 -c -xc /dev/null -include arm_neon.h In file included from : /usr/lib/gcc-cross/arm-linux-gnueabihf/11/include/arm_neon.h:71:9: internal compiler error: ‘global_options’ are modified in local context 71 | #pragma GCC pop_options | ^~~ 0xcf6aa3 cl_optimization_compare(gcc_options*, gcc_options*) /build/gcc-11-cross-76rIbd/gcc-11-cross-3ubuntu1/gcc/build/gcc/options-save.c:12589 0x8b031d handle_pragma_pop_options ../../src/gcc/c-family/c-pragma.c:1092 0x822501 c_parser_pragma ../../src/gcc/c/c-parser.c:12519 0x84e065 c_parser_external_declaration ../../src/gcc/c/c-parser.c:1758 0x84e811 c_parser_translation_unit ../../src/gcc/c/c-parser.c:1650 0x84e811 c_parse_file() ../../src/gcc/c/c-parser.c:21984 0x8ade35 c_common_parse_file() ../../src/gcc/c-family/c-opts.c:1218 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions.
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #6 from Arnd Bergmann ---
I figured out the qnx4 warning in the end: https://godbolt.org/z/hvqjr3
struct qnx4_inode_entry {
char di_status;
union {
struct {
char di_fname[16];
char di_pad[32];
};
struct {
char dl_fname[48];
};
};
};
int qnx4_readdir(struct qnx4_inode_entry *de)
{
if (!de->di_fname[0])
return 0;
if (de->di_status)
return __builtin_strnlen(de->di_fname, sizeof(de->di_fname));
else
return __builtin_strnlen(de->dl_fname, sizeof(de->dl_fname));
return 0;
}
This produces
:22:16: warning: '__builtin_strnlen' specified bound 48 exceeds source
size 16 [-Wstringop-overread]
because the first access on the object seems to decide which layout is assumed.
Changing (!de->di_fname[0]) to (!de->dl_fname[0]) shuts up the warning since
that is a longer field. This is probably enough as a workaround, if you can
confirm that the behavior of the compiler is also intentional for this input.
[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #5 from Arnd Bergmann --- (In reply to Martin Sebor from comment #4) > Most warnings designed to detect invalid accesses (not just > -Wstringop-overread but also -Wstringop-overflow and > -Wformat-overflow/-truncation, -Wrestrict, and some forms of -Warray-bounds) > use the same underlying code to determine the identity of the accessed > object, so they all should trigger if they see a constant address. Right, makes sense. > But I tested the warning with the kernel when I implemented it months ago > and don't think I saw any instances of it (though I don't see sharpsl_param > in any of my logs). I still don't. How many do you see? > > Here's the list of -Wstringop- warnings in my fresh build but I'm never sure > I use the right target. Is allyesconfig the right one? For brief testing I usually test 'allmodconfig', which has slightly better coverage and is much faster to build than 'allyesconfig'. However, most of my testing is on random configurations, with a lot of patches on top to address all the known warnings. The sharpsl_param only shows up in unusual builds since this is a legacy Arm platform that needs a custom kernel configuration and is incompatible with normal armv5 builds. Some of these tend to only show up with certain combinations of the various sanitizers and inlining decisions such as -O2 vs -Os. > $ grep Wstringop-over /src/linux-stable/gcc-master.log > arch/x86/mm/pgtable.c:437:13: warning: ‘preallocate_pmds.constprop’ > accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] > arch/x86/mm/pgtable.c:440:13: warning: ‘preallocate_pmds.constprop’ > accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] > arch/x86/mm/pgtable.c:462:9: warning: ‘free_pmds.constprop’ accessing 8 > bytes in a region of size 0 [-Wstringop-overflow=] > arch/x86/mm/pgtable.c:455:9: warning: ‘pgd_prepopulate_user_pmd’ accessing 8 > bytes in a region of size 0 [-Wstringop-overflow=] > arch/x86/mm/pgtable.c:464:9: warning: ‘free_pmds.constprop’ accessing 8 > bytes in a region of size 0 [-Wstringop-overflow=] I don't see these at the moment, maybe the kernel already got fixed for them. > mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0 > [-Wstringop-overflow=] Nor this one. > drivers/gpu/drm/i915/intel_pm.c:3093:9: warning: ‘intel_read_wm_latency’ > accessing 16 bytes in a region of size 10 [-Wstringop-overflow=] > drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’ > reading 16 bytes from a region of size 10 [-Wstringop-overread] This looks like a reasonable warning in principle, though I think the code is still correct. I have a patch for this. > drivers/gpu/drm/i915/display/intel_dp.c:4556:22: warning: > ‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4 > [-Wstringop-overread] Different bug, similar verdict: I have a patch to work around it, it seems reasonable to warn about it, but I think the code is correct. Here is one that got added in gcc-11 I just couldn't figure out: https://godbolt.org/z/sjjGc9 On this one I understand why gcc warns (pointer is compared to known constant address), but the code is correct and I don't know how to rework the code other than using #pragma to turn off the warning: In file included from arch/x86/boot/compressed/misc.c:18: In function ‘parse_elf’, inlined from ‘extract_kernel’ at arch/x86/boot/compressed/misc.c:442:2: arch/x86/boot/compressed/../string.h:15:23: error: ‘__builtin_memcpy’ reading 64 bytes from a region of size 0 [-Werror=stringop-overread] 15 | #define memcpy(d,s,l) __builtin_memcpy(d,s,l) | ^~~ arch/x86/boot/compressed/misc.c:283:9: note: in expansion of macro ‘memcpy’ 283 | memcpy(, output, sizeof(ehdr)); | ^~ This one is correct code, but has a simple workaround that does not make the code any uglier: security/commoncap.c: In function ‘cap_inode_getsecurity’: security/commoncap.c:440:33: error: ‘memcpy’ reading 16 bytes from a region of size 0 [-Werror=stringop-overread] 440 | memcpy(>data, >data, sizeof(__le32) * 2 * VFS_CAP_U32); | - if (ret < 0) + if (ret < 0 || !tmpbuf) I also got this one (with -Warray-bounds, but seems related) that looks like a real bug in the kernel: net/core/skbuff.c: In function ‘skb_find_text’: net/core/skbuff.c:3498:26: error: array subscript ‘struct skb_seq_state[0]’ is partly outside array bounds of ‘struct ts_state[1]’ [-Werror=array-bounds] I have a patch, but it needs to be discussed first. > The full breakdown with the warnings forcefully disabled in the top-level > Makefile re-enabled is below: > > DiagnosticCount UniqueFiles > -Wmissing-prototypes759 248 114 > -Wunused-const-variable=391 233 31
[Bug c/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #3 from Arnd Bergmann --- After some more analysis, I found that the -Wstringop-overread warning only happens here (and presumably in all the other cases I found) because I disabled -Warray-bounds for gcc-11. I'm still looking at -Warray-bounds to see what has changed here. There were some interesting findings from that one, but the number of added warnings made it hard to keep track of what is going on. It appears that the -Wstringop-overread warnings mostly a subset of those.
[Bug c/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #2 from Arnd Bergmann --- Ok, I see. Thanks for the explanation! I found a couple other instances (so far all false positive) and will see if any of them have a sane workaround. I'll probably just turn off both flags globally for the kernel otherwise.
[Bug rtl-optimization/99567] internal error in extract_constrain_insn with asan-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567 Arnd Bergmann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Arnd Bergmann --- No longer reproducible with latest snapshot, I assume it was fixed.
[Bug rtl-optimization/99567] internal error in extract_constrain_insn with asan-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567 --- Comment #2 from Arnd Bergmann --- *** Bug 99570 has been marked as a duplicate of this bug. ***
[Bug target/99570] internal error in extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99570 Arnd Bergmann changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Arnd Bergmann --- This was fixed at the same time as #99567, which has the same backtrace. *** This bug has been marked as a duplicate of bug 99567 ***
[Bug rtl-optimization/99567] internal error in extract_constrain_insn with asan-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567 --- Comment #1 from Arnd Bergmann --- *** Bug 99574 has been marked as a duplicate of this bug. ***
[Bug target/99574] gcc-11 unrecognizable insn in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99574 Arnd Bergmann changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Arnd Bergmann --- This was fixed at the same time as #99567, which has the same backtrace. *** This bug has been marked as a duplicate of bug 99567 ***
[Bug c/99578] New: gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
Bug ID: 99578
Summary: gcc-11 -Warray-bounds or -Wstringop-overread warning
when accessing a pointer from integer literal
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
This snippet from the Linux kernel reads a data structure from an
architecturally defined location in memory into a local copy:
struct sharpsl_param_info {
unsigned int comadj_keyword;
};
extern struct sharpsl_param_info sharpsl_param;
typedef unsigned long __kernel_size_t;
extern void * memcpy(void *, const void *, __kernel_size_t);
void sharpsl_save_param(void)
{
memcpy(_param, (void *)(0xe8ffc000), sizeof(struct
sharpsl_param_info));
}
With gcc-11, this now triggers a -Wstringop-overread warning on x86:
arch/arm/common/sharpsl_param.i: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.i:11:2: warning: ‘memcpy’ reading 4 bytes from a
region of size 0 [-Wstringop-overread]
11 | memcpy(_param, (void *)(0xe8ffc000), sizeof(struct
sharpsl_param_info));
I tried to reproduce this on godbolt.org, which apparently has a slightly
different snapshot version and instead produces -Warray-bounds warning for the
same input: https://godbolt.org/z/ve6h6b
I could not find a way to avoid this warning, other than turning off the entire
warning option globally or with a pragma. Accessing a pointer from a literal
integer value is not too unusual in the kernel and should not cause a warning.
[Bug target/99570] internal error in extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99570 --- Comment #1 from Arnd Bergmann --- I suppose this is a duplicate of #99567 and #99574, these happen with different compiler flags, but the backtrace is always the same.
[Bug target/99574] New: gcc-11 unrecognizable insn in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99574
Bug ID: 99574
Summary: gcc-11 unrecognizable insn in extract_constrain_insn,
at recog.c:2670
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
Another internal compiler error from building a linux kernel, this time on
x86-32, reduced to:
$ cat sem.c
struct {
short a;
} * b;
struct {
int c;
} * d;
int e;
short f;
void g(void) {
for (;;) {
asm("" : "=r"(e) : "g"(d->c));
int h = f - b->a;
if (h > 7)
f = h;
}
}
$ x86_64-linux-gnu-gcc-11 --version
x86_64-linux-gnu-gcc-11 (Ubuntu 11-20210306-1ubuntu1) 11.0.1 20210306
(experimental) [master revision
574e7601829:6b84c9062bc:84185598dc7470bad4e7f8c22b64e3c944efb670]
$ x86_64-linux-gnu-gcc-11 -m32 -fno-omit-frame-pointer -fno-strict-overflow
-O2 -c sem.c -Wall
sem.c: In function ‘g’:
sem.c:16:1: error: unrecognizable insn:
16 | }
| ^
(insn 9 6 7 4 (parallel [
(set (reg:SI 1 dx [92])
(asm_operands:SI ("") ("=r") 0 [
(mem:SI (mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -20 [0xffec])) [7
%sfp+-8 S4 A32]) [1 d.0_1->c+0 S4 A32])
]
[
(asm_input:SI ("g") sem.c:11)
]
[] sem.c:11))
(clobber (reg:CC 17 flags))
]) "sem.c":11:5 -1
(expr_list:REG_EQUIV (mem/c:SI (plus:SI (reg:SI 2 cx [82])
(const:SI (unspec:SI [
(symbol_ref:SI ("e") [flags 0x2] )
] UNSPEC_GOTOFF))) [1 e+0 S4 A32])
(nil)))
during RTL pass: reload
sem.c:16:1: internal compiler error: in extract_constrain_insn, at recog.c:2670
0xce2eb1 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0xce3057 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2670
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2666
0x95f537 check_rtl
../../src/gcc/lra.c:2087
0x17962bc lra(_IO_FILE*)
../../src/gcc/lra.c:2505
0x1794579 do_reload
../../src/gcc/ira.c:5827
0x1794579 execute
../../src/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/99570] New: internal error in extract_constrain_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99570
Bug ID: 99570
Summary: internal error in extract_constrain_insn
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
This happens in a couple of files when building the linux kernel with -Os,
reduced a test case to:
$ cat compaction.i
typedef struct {
long a
} b;
enum c { d } e[];
af, ah;
f(b *g) { asm("" : "=m"(g->a)); }
struct h {
_Bool ab
} static i(struct h *g, long j) {
long k = 0, l = j;
for (; j;) {
enum c ad = m();
n();
f([ad]);
k += o();
if (g && g->ab)
++j;
p();
}
q(l, k);
}
r() {
for (;;)
i(af, ah);
}
$ x86_64-linux-gnu-gcc-11 -Os -c compaction.i
compaction.i: In function ‘r’:
compaction.i:25:1: error: unrecognizable insn:
25 | }
| ^
(insn 22 20 23 4 (parallel [
(set (mem:DI (plus:DI (mult:DI (reg:DI 3 bx [orig:99 _9 ] [99])
(const_int 4 [0x4]))
(symbol_ref:DI ("e") [flags 0x2] )) [2 MEM[(struct b *)_11].a+0 S8 A64])
(asm_operands:DI ("") ("=m") 0 []
[]
[] compaction.i:6))
(clobber (reg:CC 17 flags))
]) "compaction.i":6:11 -1
(nil))
during RTL pass: reload
compaction.i:25:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0xce2eb1 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0xce3057 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2670
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2666
0x95f537 check_rtl
../../src/gcc/lra.c:2087
0x17962bc lra(_IO_FILE*)
../../src/gcc/lra.c:2505
0x1794579 do_reload
../../src/gcc/ira.c:5827
0x1794579 execute
../../src/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
$ x86_64-linux-gnu-gcc-11 --version
x86_64-linux-gnu-gcc-11 (Ubuntu 11-20210306-1ubuntu1) 11.0.1 20210306
(experimental) [master revision
574e7601829:6b84c9062bc:84185598dc7470bad4e7f8c22b64e3c944efb670]
[Bug rtl-optimization/99567] New: internal error in extract_constrain_insn with asan-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99567
Bug ID: 99567
Summary: internal error in extract_constrain_insn with
asan-stack
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
Target Milestone: ---
I ran into an internal compiler error while building linux kernels with the
kernel address sanitizer. Reduced it to this test case:
$ gcc-11 --version
gcc-11 (Ubuntu 11-20210306-1ubuntu1) 11.0.1 20210306 (experimental) [master
revision 574e7601829:6b84c9062bc:84185598dc7470bad4e7f8c22b64e3c944efb670]
$ cat tcp_ipv4.i
enum { a };
struct b {
short c;
};
int d(void);
void e(int, _Bool *);
void f(struct b *, int *);
void g(struct b *h) {
int i, l;
volatile char j;
struct b k = *h;
void *m = h + k.c;
l = *(int *)m;
asm("" : : "g"(l));
lookup:
i = j;
int n = d();
_Bool o = a;
if (i)
f(h, m);
e(n, );
goto lookup;
}
$ gcc-11 -fno-omit-frame-pointer -fsanitize=address --param
asan-instrumentation-with-call-threshold=1 --param asan-stack=1 -c -O2
-Wall tcp_ipv4.i
tcp_ipv4.i: In function ‘g’:
tcp_ipv4.i:23:1: error: unrecognizable insn:
23 | }
| ^
(insn 84 83 160 10 (parallel [
(asm_operands/v ("") ("") 0 [
(mem:SI (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -192 [0xff40])) [9
%sfp+-144 S8 A64]) [1 MEM[(int *)m_8]+0 S4 A32])
]
[
(asm_input:SI ("g") tcp_ipv4.i:14)
]
[] tcp_ipv4.i:14)
(clobber (reg:CC 17 flags))
]) "tcp_ipv4.i":14:3 -1
(nil))
during RTL pass: reload
tcp_ipv4.i:23:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0xce2eb1 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0xce3057 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2670
0x95f537 extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.c:2666
0x95f537 check_rtl
../../src/gcc/lra.c:2087
0x17962bc lra(_IO_FILE*)
../../src/gcc/lra.c:2505
0x1794579 do_reload
../../src/gcc/ira.c:5827
0x1794579 execute
../../src/gcc/ira.c:6013
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
So far this only happened on x86 targets.
[Bug sanitizer/97490] New: [10/11 Regression] false-positive -Wstringop-overflow= with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
Bug ID: 97490
Summary: [10/11 Regression] false-positive -Wstringop-overflow=
with address sanitizer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Building the Linux kernel with gcc-10.1 or higher shows a couple of warnings in
one file:
drivers/net/wireless/ath/ath9k/dynack.c:209:14: warning: writing 4 bytes into a
region of size 0 [-Wstringop-overflow=]
I manually created a reduced test case:
typedef unsigned int u32;
typedef unsigned short u16;
typedef unsigned char u8;
typedef _Bool bool;
static inline void _ether_addr_copy(u8 *dst, const u8 *src)
{
*(u32 *)dst = *(const u32 *)src;
*(u16 *)(dst + 4) = *(const u16 *)(src + 4);
}
struct _ieee80211_hdr {
u8 addr1[6];
};
struct _haddr_pair {
u8 h_dest[6];
};
struct _ath_dyn_txbuf {
u16 t_rb;
struct _haddr_pair addr[64];
};
struct _ath_dynack {
bool enabled;
struct _ath_dyn_txbuf st_rbf;
};
struct _ath_hw {
int reg_ops;
struct _ath_dynack dynack;
};
void _ath_dynack_sample_tx_ts(struct _ath_hw *ah, struct _ieee80211_hdr *hdr)
{
struct _ath_dynack *da = >dynack;
struct _haddr_pair *addr;
if (!da->enabled)
return;
addr = >st_rbf.addr[da->st_rbf.t_rb];
_ether_addr_copy(addr->h_dest, hdr->addr1);
}
$ gcc-10 -O2 -Wall -fsanitize=kernel-address -c dynack.c
test.c: In function '_ath_dynack_sample_tx_ts':
test.c:8:21: warning: writing 4 bytes into a region of size 0
[-Wstringop-overflow=]
8 | *(u32 *)dst = *(const u32 *)src;
| ^~~
test.c:26:14: note: at offset 0 to object 'enabled' with size 1 declared here
26 | bool enabled;
| ^~~
test.c:9:27: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
9 | *(u16 *)(dst + 4) = *(const u16 *)(src + 4);
| ~~^
test.c:26:14: note: at offset 0 to object 'enabled' with size 1 declared here
26 | bool enabled;
| ^~~
See also https://godbolt.org/z/K5jcM8
I checked locally that this happens on all target architectures I tried, but
not with gcc-9. The code in the kernel only produces a warning on architectures
that are assumed to allow unaligned load/store instructions, otherwise a
different ether_addr_copy() function is used.
