[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch since r15-888-gb644126237a1aa

[arnd at linaro dot org via Gcc-bugs]

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

--- Comment #7 from Arnd Bergmann  ---
I confirmed that the patch from comment #6 addresses the build warnings I see
in the kernel.

[Bug sanitizer/113214] false-positive -Wstringop-overflow warning with thread sanitizer

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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(&op);
}

$ 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

[arnd at linaro dot org via Gcc-bugs]

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&action=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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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&action=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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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&action=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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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)

[arnd at linaro dot org via Gcc-bugs]

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)

[arnd at linaro dot org via Gcc-bugs]

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)

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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 &&j(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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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(&ehdr, 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(&nscap->data, &cap->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  

[Bug c/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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(&sharpsl_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(&sharpsl_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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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

[arnd at linaro dot org via Gcc-bugs]

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(&e[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

[arnd at linaro dot org via Gcc-bugs]

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, &o);
  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

[arnd at linaro dot org via Gcc-bugs]

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 = &ah->dynack;
struct _haddr_pair *addr;

if (!da->enabled)
return;

addr = &da->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.

[Bug target/95943] New: arc -mbig-endian "inappropriate arguments" error from assembler

[arnd at linaro dot org]

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

Bug ID: 95943
   Summary: arc -mbig-endian "inappropriate arguments" error from
assembler
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Building an 'allmodconfig' linux kernel for ARC results in a failure to
assemble one file:

{standard input}: Assembler messages:
{standard input}:12347: Error: inappropriate arguments for opcode 'mpyd'
make[3]: *** [/tmp/mainline/scripts/Makefile.build:281: kernel/sched/core.o]
Error 1

With creduce, I reduced the problem to

void a(int b, int c, long long d) {
  long e = d;
  long long f = 0;
  if (e / 1000)
f = (long long)e * 1000;
  g(a, f);
}

$ arc-linux-gcc-O2 -mbig-endian  -mcpu=hs38 -c test.c
/tmp/ccfzWfgR.s: Assembler messages:
/tmp/ccfzWfgR.s:21: Error: inappropriate arguments for opcode 'mpyd'


$ arc-linux-gcc-O2 -mbig-endian  -mcpu=hs38 -S test.c -o-
.section.text
.align 4
.global a
.type   a, @function
a:
mov_s   r2,r3   ;4
add r2,r2,999
cmp r2,1998
mov.ls r2,0
mov.ls r3,0
mpyd.hi r2,r3,1000
mov_s   r1,r2   ;4
mov_s   r0,@a   ;13
b.d @g
mov_s   r2,r3   ;4
.size   a, .-a
.ident  "GCC: (GNU) 10.1.0"

This happens with at least gcc-8 through gcc-10, but not with gcc-7.5.

[Bug c/94986] New: missing diagnostic on ARM thumb2 compilation with -pg when using r7 in inline asm

[arnd at linaro dot org]

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

Bug ID: 94986
   Summary: missing diagnostic on ARM thumb2 compilation with -pg
when using r7 in inline asm
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

I reported a bug against clang for a Linux kernel failure, but 
 it was suggested that the clang behavior is probably correct in this corner
case while gcc gets it wrong, see https://bugs.llvm.org/show_bug.cgi?id=45826

echo 'void f(void) { asm("mov r7, #0" ::: "r7"); }' | arm-linux-gnueabi-gcc
-march=armv7-a -O2  -mthumb -pg -S -xc -

silently accepts an inline asm statement that clobbers the frame pointer, but
gcc rejects the same code if any of '-O0', '-fomit-frame-pointer' or
'fno-omit-frame-pointer' are used:

: In function 'f':
:1:44: error: r7 cannot be used in 'asm' here

If using r7 in this case is indeed invalid, we need to ensure the kernel does
not do this, and having gcc reject it would be helpful.

[Bug sanitizer/94881] [10 Regression] incorrect Wstringop-overflow warning with thread sanitizer since r10-5451-gef29b12cfbb4979a

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
I ran into another file that triggered this problem, reducing that one gave me
a slightly simpler test case:

struct a {
  char b[8];
};
struct e {
  unsigned c;
  struct a d[2];
};
void i(struct e *e, void *g) {
  struct e *f = e + 1;
  __builtin_memcpy(f->d[f->c].b, g, 1);
}

[Bug sanitizer/94881] New: incorrect Wstringop-overflow warning with thread sanitizer

[arnd at linaro dot org]

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

Bug ID: 94881
   Summary: incorrect Wstringop-overflow warning with thread
sanitizer
   Product: gcc
   Version: 10.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: ---

A gcc-10 snapshot from earlier this month (dated 2020-04-13) produced a
-Wstringop-overflow warning that made no sense when building the Linux kernel.
I reduced it to a small test case

https://godbolt.org/z/NyjxvH

struct a {
  char b[50];
};
struct c {
  short action;
  struct a d;
};
struct f {
  short command;
  struct c e;
};
void i(struct f *f, int *g, unsigned h) {
  struct c *j = &f->e;
  j->action = 0;
  __builtin_memcpy(&j->d.b[h], g, 16);
}

$ x86_64-linux-gcc -O2 -Wall -fsanitize=thread test.c -c
test.c:In function 'i':
test.c:15:3: warning: writing 16 bytes into a region of size 0
[-Wstringop-overflow=]
   15 |   __builtin_memcpy(&j->d.b[h], g, 16);
  |   ^~~
test.c:5:9: note: at offset 0 to object 'action' with size 2 declared here
5 |   short action;
  | ^~

[Bug sanitizer/94076] libsanitizer fails with 64-bit time_t

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
I'm not at the point of the bootstrap where I can attempt building llvm, but I
opened another report at https://bugs.llvm.org/show_bug.cgi?id=45138 anyway.

[Bug sanitizer/94076] New: libsanitizer fails with 64-bit time_t

[arnd at linaro dot org]

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

Bug ID: 94076
   Summary: libsanitizer fails with 64-bit time_t
   Product: gcc
   Version: 9.2.1
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 tried bootstrapping a debian armhf system with an experimental glibc
configured with a 64-bit time_t/off_t/ino_t, and saw several failed assertions
on 'struct dirent' and 'struct timeb':

  339 | typedef char IMPL_PASTE(assertion_failed_##_,
line)[2*(int)(pred)-1]
  |   
^
../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:333:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
  333 | #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  |  ^~~~
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1495:3:
note: in expansion of macro 'COMPILER_CHECK'
 1495 |   COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE))
  |   ^~
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1213:1:
note: in expansion of macro 'CHECK_TYPE_SIZE'
 1213 | CHECK_TYPE_SIZE(timeb);
  | ^~~
../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:339:70:
warning: size of array 'assertion_failed__1213' is not an integral
constant-expression [-Wpedantic]

In particular:
CHECK_SIZE_AND_OFFSET(dirent, d_ino);
CHECK_SIZE_AND_OFFSET(dirent, d_off);
CHECK_SIZE_AND_OFFSET(dirent, d_reclen);
CHECK_TYPE_SIZE(timeb);
CHECK_SIZE_AND_OFFSET(timeb, time);
CHECK_SIZE_AND_OFFSET(timeb, millitm);
CHECK_SIZE_AND_OFFSET(timeb, timezone);
CHECK_SIZE_AND_OFFSET(timeb, dstflag);

The same thing will likely hit on architectures that always set them to 64-bit,
as riscv32 and arc, on musl-1.2+, and on upstream glibc once that the time64
interfaces get enabled there.

[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[arnd at linaro dot org]

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

--- Comment #16 from Arnd Bergmann  ---
Right, I was on the releases/gcc-9 branch, not HEAD. Sorry about the confusion.
I applied your fix and have a working 9.2 build that can build the kernel now.
Thanks!

[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #14 from Arnd Bergmann  ---
I got the same output while building the linux kernel defconfig today, reduced
to this minimal test case:

$ cat test.c
long a, b;
int fn1() {
  char *c = (void *)b;
  while (1) {
const long d = *c = d;
do
  a++;
while (a == 5);
  }
}
$ ia64-linux-gcc -O3 -c test.c
during RTL pass: mach
lz4_decompress.c:10:1: internal compiler error: in sel_target_adjust_priority,
at sel-sched.c:3334
   10 | }

Reproduced both with 9.2 and current HEAD 
$ ia64-linux-gcc --version
ia64-linux-gcc (GCC) 9.2.1 20200211

[Bug rtl-optimization/92657] High stack usage due ftree-ch

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #5 from Arnd Bergmann  ---
Submitted a workaround for the warning that triggered this bug report in the
linux kernel:

https://lore.kernel.org/lkml/20200104215156.689245-1-a...@arndb.de/

[Bug sanitizer/84863] false-positive -Warray-bounds warning with -fsanitize-coverage=object-size

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
The problem in the kernel then is that we then have to turn off the sanitizers
for the 'allmodconfig' build, since the recommended minimum regression testing
for kernel changes involves building a kernel with all options (including
UBSAN) enabled and checking that there are no compiler warnings.

This means we would fail to catch any build regressions in the kernel part of
UBSAN, as well as any legitimate warnings that are only seen when the
sanitizers are active.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #32 from Arnd Bergmann  ---
(In reply to Martin Liška from comment #31)
> (In reply to Arnd Bergmann from comment #30)
> > (In reply to Martin Liška from comment #29)
> > > Which is very promising improvement I would say.
> > 
> > Agreed, this looks great. With most of the warnings against the
> > 2048 byte limit gone, we can probably work around the remaining
> > ones by doing local code changes in the kernel. I had patches for
> > some of these in the past, which I can dig up then.
> 
> Just out of curiosity. Am I right that you're using KASAN build for
> syzkaller or an other fuzzer? If so, I bet you can't hit most of the
> stack overflows in drivers as you very probably don't have the
> real hardware?

No, I don't do any fuzzing myself. The side project that I'm
interested in here is to build the kernel in all random
configurations without compile-time warnings that may indicate
bugs. I tend to build several hundred such kernels per day to
catch new bugs in both the (linux-next) kernel and in the
toolchain (clang and gcc).

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #30 from Arnd Bergmann  ---
(In reply to Martin Liška from comment #29)
> I'm got a patch candidate for which I did testing of allmodconfig
> configuration.
> Sorting all violations against 2KB of stack memory:
> 
> Before:
> TOTAL warnings: 185
>  
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5653:1: 23624
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4518:1: 14144
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3882:1: 11504
> lib/atomic64_test.c:250:1: 11192
> lib/atomic64_test.c:148:1: 10352

This is with -fsanitize-address-use-after-scope, right?

> after:
> 
> TOTAL warnings: 43
>  
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5653:1: 11880
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4518:1:  7264
> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3882:1:  5840
> lib/atomic64_test.c:250:1:  5656
> lib/atomic64_test.c:148:1:  5232
>
> Which is very promising improvement I would say.

Agreed, this looks great. With most of the warnings against the
2048 byte limit gone, we can probably work around the remaining
ones by doing local code changes in the kernel. I had patches for
some of these in the past, which I can dig up then.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #13 from Arnd Bergmann  ---
(In reply to Andreas Schwab from comment #12)
> arch/h8300/kernel/sim-console.c:  register const int fd __asm__("er0") = 
> 1;

I found that too, and then noticed it is already fixed in linux-next:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=14cf9451be78f8a

Ard points out that most of the other ones are pointers to const data, which
are not a problem. This leaves the arm put_user bug as the only definite
problem that needs to be addressed in older kernels.

The three arch/riscv instances of 'const register unsigned long gp __asm__
("gp")' are different because they are never passed into an inline assembly as
far as I can tell. This seems to be unsupported for local register variables
according to the gcc documentation, but if that's a problem, it's unrelated to
this bug.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #11 from Arnd Bergmann  ---
I have checked all instances of 'register const' or 'const register' in the
current linux kernel (4.18-rc), and we never assign a constant expression to
any of them, so I guess none of them are affected:

arch/arm/include/asm/uaccess.h: register const void __user *__p
asm("r0") = __ptr;  \
arch/h8300/kernel/sim-console.c:register const char *_ptr
__asm__("er1") = s;
arch/h8300/kernel/sim-console.c:register const unsigned _len
__asm__("er2") = n;
arch/mips/include/asm/uaccess.h:register const void __user *__cu_from_r
__asm__("$5");  \
arch/mips/include/asm/uaccess.h:register const void *__cu_from_r
__asm__("$5"); \
arch/riscv/kernel/process.c:const register unsigned long gp __asm__
("gp");
arch/riscv/kernel/stacktrace.c: const register unsigned long current_sp
__asm__ ("sp");
arch/riscv/kernel/stacktrace.c: const register unsigned long current_sp
__asm__ ("sp");

Should we drop the 'const' for all of them as a rule? If there is no use case
for ever using a 'const register' variable and it can lead to bugs, should gcc
warn about it in the future?

Should this issue be mentioned in the documentation in
https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html?

I also checked all instances in linux-4.4, and the ARM put_user() helper is the
only one I see that gets a constant expression input, so I suppose that is all
that needs to be fixed in backports, unless someone thinks we should get rid of
all them in backports as well.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
Reproduced on arm64 and x86 as well, see x86 version:

void fn1() {
   register const int h asm("edx") = 1;
__asm__(".ifnc %0,edx; .err; .endif" :: "r"(h));
}

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
(In reply to Andreas Schwab from comment #4)
> Why are you using empty constraints when a register is required?

creduce did that, it had no effect on the result. The original source looks
like:

#define __get_user_x_64t(__r2, __p, __e, __l, __s)  \
   __asm__ __volatile__ (   \
__asmeq("%0", "r0") __asmeq("%1", "r2") \
__asmeq("%3", "r1") \
"bl __get_user_64t_" #__s   \
: "=&r" (__e), "=r" (__r2)  \
: "0" (__p), "r" (__l)  \
: __GUP_CLOBBER_##__s)

[Bug target/86673] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #2 from Arnd Bergmann  ---
Forcing constant inputs for put_user to be read from a volatile variable avoids
this problem and lets me cleanly build all files that showed it.

diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 35c9db857ebe..23e92a9a5ef4 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -251,7 +251,8 @@ extern int __put_user_8(void *, unsigned long long);
({  \
unsigned long __limit = current_thread_info()->addr_limit - 1;
\
const typeof(*(p)) __user *__tmp_p = (p);   \
-   register const typeof(*(p)) __r2 asm("r2") = (x);   \
+   const typeof(*(p)) __x = (x);   \
+   register const typeof(*(p)) __r2 asm("r2") = READ_ONCE(__x);   
\
register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \
register unsigned long __l asm("r1") = __limit; \
register int __e asm("r0"); \

This confirms that constant inputs are what leads to the problem.

[Bug target/86673] inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

--- Comment #1 from Arnd Bergmann  ---
Further inspection shows that this happens for the cases where the input
argument to the inline asm is a compile-time constant, but not for those that
are variables.

[Bug target/86673] New: inline asm sometimes ignores 'register asm("reg")' declarations

[arnd at linaro dot org]

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

Bug ID: 86673
   Summary: inline asm sometimes ignores 'register asm("reg")'
declarations
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
      Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 44438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44438&action=edit
linux/net/core/scm.o, preprocessed

Building older linux kernels for ARM with a gcc-8.1 compiler has triggered a
check for broken compiler versions, which compares the register number that is
used in an inline assembly statement with the expected value, for an argument
that was declared with the 'register foo asm ("reg")' syntax described in the
gcc manual under "Specifying Registers for Local Variables".

The diagnostic from the assembler is

$ arm-linux-gnueabi-gcc -Wall -O2 scm.i -c -Wno-pointer-sign
-fno-strict-aliasing
/tmp/ccCGMQmS.s:648: Error: .err encountered
/tmp/ccCGMQmS.s:679: Error: .err encountered

Unfortunately, a change made to the kernel a few years ago had made this go
unnoticed as everyone was testing gcc-8.1 only on more recent kernels that did
not run into the particular check, but may have run into the bug without
triggering the check. Architectures other than arm may also be affected, but
nothing else has this check.

I tested gcc-8.1.0 and today's gcc-8.1.1 (r262956), both with the same result.
I attached one of the files that showed the problem, and reduced this using
creduce to:

int a, c, d, e;
long b;
void fn1() {
  int f = ({
({
  long g = b, j = g;
  register const typeof(c) h asm("r2") = 1, i = d;
  __asm__(".ifnc %2,r2; .err; .endif\n\t"
"bl __put_user_4"
  : "=&r"(e)
  : ""(i), ""(h), ""(j));
  e;
});
  });
  a = f;
}

[Bug libgcc/85869] libgcc fails to build in canadian cross: cet.h not found

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

   Keywords|build   |
 Target|x86_64-*-*, i?86-*-*|
   Host|powerpc64le |
  Build|x86_64-*-*  |

--- Comment #2 from Arnd Bergmann  ---
Ah, found a bug in my scripts: I had built and installed a i386 cross compiler
from these sources, but passed the wrong PATH variable, so it picked up a
native compiler of the wrong version instead. This works fine now after fixing
my script, sorry about the false-positive report.

A related problem still seems to happen for the
build=x86_64/host=ppc64le/target=x86_64 cross compiler when building the 32-bit
libgcc: I have the correct x86_64-linux-gcc binary in the PATH here, and this
gets used for the 64-bit libgcc, but when building the 32-bit libgcc, it uses
'cc -m32' instead, which comes from /usr/bin/.

After manually removing the '/usr/bin/cc -> gcc' symlink, that appears to work
fine as well, but I don't see why that symlink causes this behavior.

[Bug libgcc/85869] New: libgcc fails to build in canadian cross: cet.h not found

[arnd at linaro dot org]

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

Bug ID: 85869
   Summary: libgcc fails to build in canadian cross: cet.h not
found
   Product: gcc
   Version: 8.1.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 cross-building (for host=ppc64le) a set of cross-toolchain on an x86_64
build system. This fails for the target=i386 compiler with this error:

In file included from /home/arnd/git/gcc/libgcc/config/i386/avx_savms64.S:2:0:
/home/arnd/git/gcc/libgcc/config/i386/savms64.h:26:10: fatal error: cet.h: No
such file or directory

The compiler was configured using

/home/arnd/git/gcc/configure --host=ppc64le-linux-gnu --target=i386-linux
--enable-targets=all
--prefix=/home/arnd/cross/ppc64le/gcc-8.1.0-nolibc/ppc64le-linux-gnu/i386-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release

This was no problem in earlier releases, or on other target architectures (not
sure about target=x86_64, which fails differently for me). I have not tried
other host architectures but would assume that this is not ppc64le specific.

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

[arnd at linaro dot org]

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

--- Comment #6 from Arnd Bergmann  ---
I found that older versions (gcc-5 and before) did not warn when the type gets
changed to bitfield of '_Bool' rather than 'unsigned int'. It seems that this
was only because they tested each bit separately in the _Bool case rather than
combining the first two comparisons into a &3 mask.

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
One more instance got added to the kernel today:

In file included from /git/arm-soc/include/trace/perf.h:90,
 from /git/arm-soc/include/trace/define_trace.h:97,
 from /git/arm-soc/include/trace/events/fscache.h:537,
 from /git/arm-soc/fs/fscache/internal.h:32,
 from /git/arm-soc/fs/fscache/main.c:20:
/git/arm-soc/include/trace/events/fscache.h: In function
'perf_trace_fscache_netfs':
/git/arm-soc/include/trace/events/fscache.h:200:1261: warning: 'strncpy'
specified bound 8 equals destination size [-Wstringop-truncation]
 TRACE_EVENT(fscache_netfs,

Same as the one from comment #5, this one happen for -fsanitize=kernel-address
and is based on simple code that we don't warn for without sanitizer:

   strncpy(__entry->name, netfs->name, 8);
   __entry->name[7]= 0;

I can probably work around that by turning off -Wstringop-truncation whenever
sanitizers enabled in the kernel configuration (we already do that for
-Wmaybe-uninitialized), if this one is unlikely to get fixed before the gcc-8
release.

[Bug tree-optimization/85301] New: bitfield check causes maybe-uninitialized warning

[arnd at linaro dot org]

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

Bug ID: 85301
   Summary: bitfield check causes maybe-uninitialized warning
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

A Linux kernel patch that changed a few flags from type 'int' to a single-bit
bitfield caused a false-positive warning. I reduced a test case to

struct tick_sched {
#ifdef USE_BITFIELD
  unsigned int tick_stopped : 1;
  unsigned int idle_active : 1;
#else
  int tick_stopped;
  int idle_active;
#endif
};
long ktime_get();
void __tick_nohz_idle_restart_tick(long);
struct tick_sched tick_nohz_idle_exit_ts;
void tick_nohz_idle_exit(void) {
  long now;
  if (tick_nohz_idle_exit_ts.idle_active ||
tick_nohz_idle_exit_ts.tick_stopped)
now = ktime_get();
  if (tick_nohz_idle_exit_ts.tick_stopped)
__tick_nohz_idle_restart_tick(now);
}

$ gcc  -c tick-sched.c -Wall -O2 -DUSE_BITFIELD
tick-sched.c: In function ‘tick_nohz_idle_exit’:
tick-sched.c:19:5: warning: ‘now’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 __tick_nohz_idle_restart_tick(now);
$ gcc  -c tick-sched.c -Wall -O2
# no warning

It's easy to work around the warning, e.g. by copying the flag into a temporary
variable, but it looks like this is something that gcc could handle better.

I looked through the list of false-positive Wmaybe-uninitialized bug reports,
but couldn't find one that looks related to this particular one.

[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
Improving the optimizer will definitely help this one, but not the other
instances I found. Here's a list of the remaining warnings that got introduced
in the linux kernel by r257857 for reference:

https://elixir.bootlin.com/linux/v4.16/source/drivers/acpi/acpi_processor.c#L330
invalid_logical_cpuid() has checked the 'id' variable to be a positive number
(i.e. not an error value), so it's assumed to be in the range of [0,
2147483647] by the compiler, while we know it it's in the range of [0,
CONFIG_NR_CPUS] when the id is positive. I'd work around that by adding a '<
CONFIG_NR_CPUS' check in invalid_logical_cpuid.

https://elixir.bootlin.com/linux/v4.16/source/drivers/gpu/drm/imx/imx-ldb.c#L634
The one referenced reported here, ideally handled better by gcc

https://elixir.bootlin.com/linux/v4.16/source/drivers/usb/gadget/function/rndis.c#L900
We check the 'id' for a positive number, negative values are error codes. 
rndis_get_nr() otherwise returns the first available number, so we can assume
it's a low number (you won't have billions of USB network interfaces), but
making the buffer larger is a safer fix.

https://elixir.bootlin.com/linux/v4.16/source/drivers/usb/gadget/udc/fsl_udc_core.c#L2497
We know that max_ep is a small number, but gcc cannot know this, so the loop
index has a lower bound but no upper bound. Would work around this by
increasing the buffer size from 14 to 16 bytes.

https://elixir.bootlin.com/linux/v4.16/source/sound/pci/cmipci.c#L3157
We check for an upper bound but not a lower bound on a signed integer that we
know contains a positive number. The warning seems reasonable here, and I would
make the variable unsigned.

https://elixir.bootlin.com/linux/v4.16/source/drivers/scsi/ch.c#L937
ch->minor is known to be less than 128 CH_MAX_DEVS here, but gcc cannot see
this. Again, idr_alloc() returns a negative code in case of an error, so gcc
sees that the variable has a lower bound, but not the upper bound. Would work
around this using a %hhi modifier.

https://elixir.bootlin.com/linux/v4.16/source/drivers/power/supply/sbs-battery.c#L559
sbs_read_word_data() returns either a negative error code or a positive 16-bit
number. Would work around that using the %hx modifier.

https://elixir.bootlin.com/linux/v4.16/source/net/bluetooth/hci_core.c#L3093
idr_alloc() once more returns a negative number on error, or a positive number
that may have an upper bound (the third argument to idr_alloc). Here we should
specify the upper bound (1), but gcc won't see it and still warn, so we
also need a way to tell it that 'id' is a four-digit number. Using the %hi
format won't work as that is still five digits.

To summarize: For this particular project (linux kernel), these added tend to
be slightly annoying false-positives, but we can work around that with a
handful of simple patches. In five of the eight cases, gcc sees a limited range
of [0, 2147483647] because of an explicit check for an error code. I don't know
how common that code pattern is in other projects, but for us it would be more
logical to treat this like the unbounded range in -Wformat-overflow=2 rather
than a range with a known bound for -Wformat-overflow=1.

[Bug tree-optimization/85175] [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Martin Sebor from comment #2)

> So with the change above GCC is doing a better but imperfect job of
> determining the range.  Changing the variable to unsigned constrains the
> lower bound to zero and eliminates the warning even at -Os.

Ok, so this is actually the same thing I saw with seven other files in the
kernel (out of several hundred randconfig kernel builds on three
architectures). In each case, we now have a signed integer range that appears
to be constrained on one side after r257857, e.g. [-2147483647, 68] or [1,
2147483647] based on a partial range check, but the warning is still a false
positive in the end.

The one such warning we gained in the kernel that makes sense was this one (not
sent yet):

commit c18e88d296264d76f1a242ae95a43681cf198078
Author: Arnd Bergmann 
Date:   Tue Apr 3 09:45:35 2018 +0200

bluetooth: fix hci name overflow

gcc-8 warns that the index of the hci device could overflow the eight
character array:

net/bluetooth/hci_core.c: In function 'hci_register_dev':
net/bluetooth/hci_core.c:3093:26: error: '%d' directive writing between 1
and 10 bytes into a region of size 5 [-Werror=format-overflow=]
  sprintf(hdev->name, "hci%d", id);
  ^~
net/bluetooth/hci_core.c:3093:22: note: directive argument in the range [0,
2147483647]
  sprintf(hdev->name, "hci%d", id);
  ^~~
net/bluetooth/hci_core.c:3093:2: note: 'sprintf' output between 5 and 14
bytes into a destination of size 8
  sprintf(hdev->name, "hci%d", id);

This uses snprintf() to enforce a valid string, and limits the range of
the integer to 0... In practice this should not matter as we would
not be able connect more than  bluetooth hci's simultaneously.

Signed-off-by: Arnd Bergmann 

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 40d260f2bea5..9e2ad444d799 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -3075,13 +3075,14 @@ int hci_register_dev(struct hci_dev *hdev)

/* Do not allow HCI_AMP devices to register at index 0,
 * so the index can be used as the AMP controller ID.
+* Ensure the name fits into eight characters id < 1.
 */
switch (hdev->dev_type) {
case HCI_PRIMARY:
-   id = ida_simple_get(&hci_index_ida, 0, 0, GFP_KERNEL);
+   id = ida_simple_get(&hci_index_ida, 0, 1, GFP_KERNEL);
break;
case HCI_AMP:
-   id = ida_simple_get(&hci_index_ida, 1, 0, GFP_KERNEL);
+   id = ida_simple_get(&hci_index_ida, 1, 1, GFP_KERNEL);
break;
default:
return -EINVAL;
@@ -3090,7 +3091,7 @@ int hci_register_dev(struct hci_dev *hdev)
if (id < 0)
return id;

-   sprintf(hdev->name, "hci%d", id);
+   snprintf(hdev->name, sizeof(hdev->name), "hci%d", id);
hdev->id = id;

BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);

The other new warnings are either the same kind as this one (the compiler
should be able to figure it out), or the sort where the compiler is technically
right about the string overflow based on the types, but we can easily prove
that the range is more limited like in the ida_simple_get() case with correct
limits (this is an extern function that returns an unused number within a
strict range).

Would it be sensible to only warn with -Wformat-overflow=1 on a signed integer
if the overflow happens with an actual known limit, but not if the limit is
euqal to the minimum/maximum representable numbers? The documentation for
-Wformat-overflow=2 isn't completely clear on what behavior was intended here
for the =1 and =2 case if the range is only bounded on one side.

[Bug tree-optimization/85175] New: [8 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os

[arnd at linaro dot org]

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

Bug ID: 85175
   Summary: [8 regression] false-positive -Wformat-overflow=
warning with gcc-8 -Os
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

This snippet from the Linux kernel produces a bogus warning when built with gcc
-Os, using a recent snapshot (20180402) A two months older version did not
produce the warning, and building with -O2 is also fine. Reduced test case:

$ gcc-8.0.1 -Os -Wall -c test.c

int of_property_read_u32(int *out_value);
int imx_ldb_bind(void)
{
int i;
for (i = 0; i < 4; i++) {
char clkname[16];
__builtin_sprintf(clkname, "di%d_sel", i);
}
return of_property_read_u32(&i);
}

imx-ldb.i: In function 'imx_ldb_bind':
imx-ldb.i:7:35: warning: '_sel' directive writing 4 bytes into a region of size
between 3 and 13 [-Wformat-overflow=]
   __builtin_sprintf(clkname, "di%d_sel", i);

[Bug sanitizer/84863] New: false-positive -Warray-bounds warning with -fsanitize-coverage=object-size

[arnd at linaro dot org]

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

Bug ID: 84863
   Summary: false-positive -Warray-bounds warning with
-fsanitize-coverage=object-size
   Product: gcc
   Version: 8.0.1
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 43655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43655&action=edit
linux/net/xfrm/xfrm_output.c, preprocessed, not reduced.

Among the linux kernel build warnings I see from enabling sanitizers
(CONFIG_UBSAN_SANITIZE_ALL), this is one that seems interesting and not yet
reported:

In file included from /git/arm-soc/include/linux/kernel.h:10,
 from /git/arm-soc/include/linux/list.h:9,
 from /git/arm-soc/include/linux/module.h:9,
 from /git/arm-soc/net/xfrm/xfrm_output.c:13:
/git/arm-soc/net/xfrm/xfrm_output.c: In function 'xfrm_output_resume':
/git/arm-soc/include/linux/compiler.h:251:20: error: array subscript 4 is above
array bounds of 'struct nf_hook_entries *[3]' [-Werror=array-bounds]
   __read_once_size(&(x), __u.__c, sizeof(x));  \
^~~~
/git/arm-soc/include/linux/compiler.h:257:22: note: in expansion of macro
'__READ_ONCE'
 #define READ_ONCE(x) __READ_ONCE(x, 1)
  ^~~
/git/arm-soc/include/linux/rcupdate.h:351:48: note: in expansion of macro
'READ_ONCE'
  typeof(*p) *p1 = (typeof(*p) *__force)READ_ONCE(p); \
^
/git/arm-soc/include/linux/rcupdate.h:488:2: note: in expansion of macro
'__rcu_dereference_check'
  __rcu_dereference_check((p), (c) || rcu_read_lock_held(), __rcu)
  ^~~
/git/arm-soc/include/linux/rcupdate.h:546:28: note: in expansion of macro
'rcu_dereference_check'
 #define rcu_dereference(p) rcu_dereference_check(p, 0)
^
/git/arm-soc/include/linux/netfilter.h:219:15: note: in expansion of macro
'rcu_dereference'
   hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
   ^~~

The original function looks like

static inline int nf_hook(u_int8_t pf, unsigned int hook, struct net *net,
  struct sock *sk, struct sk_buff *skb,
  struct net_device *indev, struct net_device *outdev,
  int (*okfn)(struct net *, struct sock *, struct
sk_buff *))
{
struct nf_hook_entries *hook_head = NULL;
int ret = 1;

rcu_read_lock();
switch (pf) {
case NFPROTO_IPV4:
hook_head = rcu_dereference(net->nf.hooks_ipv4[hook]);
break;
case NFPROTO_IPV6:
hook_head = rcu_dereference(net->nf.hooks_ipv6[hook]);
break;
case NFPROTO_ARP:
#ifdef CONFIG_NETFILTER_FAMILY_ARP
hook_head = rcu_dereference(net->nf.hooks_arp[hook]);
#endif
break;
case NFPROTO_BRIDGE:
#ifdef CONFIG_NETFILTER_FAMILY_BRIDGE
hook_head = rcu_dereference(net->nf.hooks_bridge[hook]);
#endif
break;
#if IS_ENABLED(CONFIG_DECNET)
case NFPROTO_DECNET:
hook_head = rcu_dereference(net->nf.hooks_decnet[hook]);
break;
#endif
default:
WARN_ON_ONCE(1);
break;
}

where the net->nf.hooks_* fields all have different sizes. The function is
called with constant arguments for 'pf' and 'hook', and for this caller, the
latter is out of range for the net->nf.hooks_arp[] array, but in a line that
is never reached. Reproduced with all versions that support the object-size
sanitizer (gcc-5 through 8).

With the attached preprocessed file, reproduce with

$ arm-linux-gnueabi-gcc-8.0.1 -Wall -O2 -c net/xfrm/xfrm_output.i -Werror  
-fsanitize=object-size  -fno-strict-aliasing

The warning also shows up with an x86 compiler, but that causes other problems.
I can produce a reduced version that works on x86 if needed.

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
Created attachment 43586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43586&action=edit
drivers/gpu/drm/drm_property.c, preprocessed

I found another case that appears to be related but not the same, attaching
another (non-reduced) file for reference. The code that triggered a warning
this time is:

strncpy(property->name, name, DRM_PROP_NAME_LEN);
property->name[DRM_PROP_NAME_LEN-1] = '\0';

but unlike the first one, this only happens with -fsanitize=kernel-address but
not with -fsanitize-coverage=trace-pc:

$ x86_64-linux-gcc-8.0.1 -fno-strict-aliasing -O2 -Wall -S drm_property.i  
-fsanitize=kernel-address

/git/arm-soc/drivers/gpu/drm/drm_property.c: In function 'drm_property_create':
/git/arm-soc/include/linux/string.h:254:9: warning: '__builtin_strncpy'
specified bound 32 equals destination size [-Wstringop-truncation]
  return __builtin_strncpy(p, q, size);
 ^
/git/arm-soc/drivers/gpu/drm/drm_property.c: In function
'drm_property_add_enum':
/git/arm-soc/include/linux/string.h:254:9: warning: '__builtin_strncpy'
specified bound 32 equals destination size [-Wstringop-truncation]
  return __builtin_strncpy(p, q, size);
 ^
/git/arm-soc/include/linux/string.h:254:9: warning: '__builtin_strncpy'
specified bound 32 equals destination size [-Wstringop-truncation]
  return __builtin_strncpy(p, q, size);
 ^

[Bug sanitizer/84732] New: false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[arnd at linaro dot org]

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

Bug ID: 84732
   Summary: false-positive -Wstringop-truncation warning with
-fsanitize-coverage=trace-pc
   Product: gcc
   Version: 8.0.1
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 43576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43576&action=edit
linux/drivers/staging/lustre/lnet/lnet/lib-socket.c, preprocessed, not reduced

I ran into this warning for what looks like correct code in the linux kernel
that we should not warn about:

$ aarch64-linux-gcc-8.0.1 -fno-strict-aliasing -Wno-pointer-sign
-fsanitize-coverage=trace-pc  -Wall -O2 -c lib-socket.i
In file included from /git/arm-soc/arch/arm64/include/asm/processor.h:37,
 from /git/arm-soc/arch/arm64/include/asm/spinlock.h:21,
 from /git/arm-soc/include/linux/spinlock.h:88,
 from /git/arm-soc/include/linux/wait.h:9,
 from /git/arm-soc/include/linux/net.h:23,
 from
/git/arm-soc/drivers/staging/lustre/lnet/lnet/lib-socket.c:37:
/git/arm-soc/drivers/staging/lustre/lnet/lnet/lib-socket.c: In function
'lnet_ipif_query':
/git/arm-soc/include/linux/string.h:254:9: warning: '__builtin_strncpy'
specified bound 16 equals destination size [-Wstringop-truncation]
  return __builtin_strncpy(p, q, size);
 ^
/git/arm-soc/include/linux/string.h:254:9: warning: '__builtin_strncpy'
specified bound 16 equals destination size [-Wstringop-truncation]
  return __builtin_strncpy(p, q, size);
 ^
/git/arm-soc/include/linux/string.h:254:9: warning: '__builtin_strncpy'
specified bound 16 equals destination size [-Wstringop-truncation]
  return __builtin_strncpy(p, q, size);
 ^

See
https://elixir.bootlin.com/linux/v4.15/source/drivers/staging/lustre/lnet/lnet/lib-socket.c#L99
for the original source code. Without -fsanitize-coverage=trace-pc, the
strlen() comparison is sufficient to avoid that warning, with
fsanitize=coverage=trace-pc, that logic fails:

if (strlen(name) > sizeof(ifr.ifr_name) - 1)
return -E2BIG;
strncpy(ifr.ifr_name, name, sizeof(ifr.ifr_name));


I can probably create a reduced test case if that helps.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #26 from Arnd Bergmann  ---
(In reply to Martin Liška from comment #25)
> (In reply to Arnd Bergmann from comment #24)
> 
> Ok, I don't have problem to implement the similar behavior in GCC 9. Looks
> most
> of warnings are in drivers. That should not be problem as I guess KASAN
> build is
> mainly used in a qemu machine (with syzkaller)? Thus exotic drivers should
> not
> be needed?

I actually have no idea in what other ways it may be used, though I didn't
think that running syzkaller was the only use case. It always feels like most
bugs in the kernel are in obscure drivers, but then most of the kernel code
consists of obscure drivers ;-)

Here are some warnings in code that is actually being run. For the full output
I see on linux-next, have a look at https://pastebin.com/CMJiUsuR. There
are a couple of other warnings mixed in there as well that I'm working on
addressing, but it's mainly the stack overflow once I turn on
CONFIG_KASAN_EXTRA.

arch/x86/kernel/cpu/mshyperv.c:261:1: warning: the frame size of 2704 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
arch/x86/kvm/emulate.c:2552:1: warning: the frame size of 2128 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
drivers/acpi/nfit/core.c:3168:1: warning: the frame size of 3952 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
drivers/firmware/efi/test/efi_test.c:688:1: warning: the frame size of 2400
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table.c:83:1: warning:
the frame size of 3760 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/md/md.c:8561:1: warning: the frame size of 2544 bytes is larger than
2048 bytes [-Wframe-larger-than=]
drivers/net/bonding/bond_netlink.c:677:1: warning: the frame size of 2096 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
fs/btrfs/relocation.c:1202:1: warning: the frame size of 4272 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than
2048 bytes [-Wframe-larger-than=]
fs/jbd2/commit.c:1128:1: warning: the frame size of 3728 bytes is larger than
2048 bytes [-Wframe-larger-than=]
fs/nfs/pnfs.c:1892:1: warning: the frame size of 2672 bytes is larger than 2048
bytes [-Wframe-larger-than=]
fs/ntfs/mft.c:2756:1: warning: the frame size of 2352 bytes is larger than 2048
bytes [-Wframe-larger-than=]
fs/userfaultfd.c:1824:1: warning: the frame size of 2256 bytes is larger than
2048 bytes [-Wframe-larger-than=]
fs/xfs/libxfs/xfs_rmap.c:1334:1: warning: the frame size of 2384 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
kernel/rcu/tree.c:2282:1: warning: the frame size of 3160 bytes is larger than
2048 bytes [-Wframe-larger-than=]
lib/rbtree.c:481:1: warning: the frame size of 2520 bytes is larger than 2048
bytes [-Wframe-larger-than=]
mm/khugepaged.c:1560:1: warning: the frame size of 2976 bytes is larger than
2048 bytes [-Wframe-larger-than=]
mm/migrate.c:2129:1: warning: the frame size of 2104 bytes is larger than 2048
bytes [-Wframe-larger-than=]
mm/page_alloc.c:3247:1: warning: the frame size of 4584 bytes is larger than
2048 bytes [-Wframe-larger-than=]
mm/vmscan.c:1350:1: warning: the frame size of 5072 bytes is larger than 2048
bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1446:1: warning: the frame size of 2592 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/core/ethtool.c:2832:1: warning: the frame size of 3376 bytes is larger than
2048 bytes [-Wframe-larger-than=]
net/core/rtnetlink.c:1631:1: warning: the frame size of 2272 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/mac80211/util.c:2188:1: warning: the frame size of 2464 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
net/rxrpc/recvmsg.c:603:1: warning: the frame size of 2424 bytes is larger than
2048 bytes [-Wframe-larger-than=]
net/sctp/socket.c:7271:1: warning: the frame size of 2704 bytes is larger than
2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1938:1: warning: the frame size of 4248 bytes is larger
than 2048 bytes [-Wframe-larger-than=]

> The middle red zone is only 32B. So I don't understand why 'Size' not used
> for red zone
> calculation?

No idea.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #24 from Arnd Bergmann  ---
(In reply to Martin Liška from comment #23)

> That's definitely possible for GCC 9. Question is whether such change will
> be sufficient for you. Do you expect it will reduce stack usage in the
> desired way?

I've recreated my original finding, comparing a clang-5 release against a
recent gcc-8 snapshot. Building an x86 allmodconfig kernel with clang, I get 78
-fsanitize-address-use-after-scope warnings against a 2048 byte limit, the
largest ones are:

drivers/usb/misc/sisusbvga/sisusb.c:1880:12: warning: stack frame size of 6776
bytes in function 'sisusb_init_gfxcore' [-Wframe-larger-than=]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c:1521:1: warning: stack frame
size of 5176 bytes in function 'gk104_ram_new_' [-Wframe-larger-than=]
drivers/usb/misc/sisusbvga/sisusb.c:1750:12: warning: stack frame size of 5112
bytes in function 'sisusb_set_default_mode' [-Wframe-larger-than=]
drivers/net/wireless/atmel/atmel.c:1307:5: warning: stack frame size of 5016
bytes in function 'atmel_open' [-Wframe-larger-than=]
net/core/ethtool.c:2549:5: warning: stack frame size of 4568 bytes in function
'dev_ethtool' [-Wframe-larger-than=]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:19216:6: warning:
stack frame size of 4312 bytes in function 'wlc_phy_init_nphy'
[-Wframe-larger-than=]
drivers/media/usb/em28xx/em28xx-dvb.c:1129:12: warning: stack frame size of
3992 bytes in function 'em28xx_dvb_init' [-Wframe-larger-than=]
drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c:6802:24: warning:
stack frame size of 3960 bytes in function 'load_capture_binaries'
[-Wframe-larger-than=]
drivers/staging/wlan-ng/cfg80211.c:454:12: warning: stack frame size of 3864
bytes in function 'prism2_connect' [-Wframe-larger-than=]
drivers/staging/wilc1000/host_interface.c:2480:13: warning: stack frame size of
3704 bytes in function 'host_if_work' [-Wframe-larger-than=]


With gcc-8, the same configuration has 179 warnings, including:

drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size
of 23632 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:4515:1: warning: the frame size
of 14056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:3879:1: warning: the frame size
of 11504 bytes is larger than 2048 bytes [-Wframe-larger-than=]
lib/atomic64_test.c:250:1: warning: the frame size of 11192 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
lib/atomic64_test.c:148:1: warning: the frame size of 10360 bytes is larger
than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt73usb.c:1294:1: warning: the frame size of
8680 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than
2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:8655:1: warning: the frame size
of 6456 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3090:1: warning: the frame size of 5872
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt61pci.c:1647:1: warning: the frame size of
5792 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1595:1: warning: the frame size of 5304
bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/scsi/fnic/fnic_trace.c:451:1: warning: the frame size of 5000 bytes is
larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2417:1: warning: the frame size
of 4912 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4265:1: warning: the frame size of 4840
bytes is larger than 2048 bytes [-Wframe-larger-than=]

Comparing against a 3072 byte limit, I get 18 warnings for clang vs 54 for
gcc-8. The detailed analysis of some of those warnings last year had shown that
the difference can be traced almost entirely to simple scalar variables that
use 64 bytes redzone with gcc but only 16 bytes with clang.

[Bug sanitizer/81715] asan-stack=1 redzone allocation is too inflexible

[arnd at linaro dot org]

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

--- Comment #22 from Arnd Bergmann  ---
(In reply to Jakub Jelinek from comment #20)
> I haven't heard any answer to #c16 whether it actually helped the kernel or
> not.

Sorry about that. Yes, it definitely helped the kernel a lot. At this point, we
also have localized workarounds to the same effect (using local variables
instead of accessing inline function arguments) in all functions that exceeded
the arbitrary 2048 byte stack size limit, and backported into the 4.4 kernel
and later, but with the newer gcc releases, we also get a lower stack
consumption for lots of other functions that were high but below that limit.

I had hoped that we could also do this on gcc-7 branch without KASAN, as high
stack consumption is always problematic for the kernel, and the same functions
that got bumped over the warning limit with KASAN still suffer from wasted
stack space on older compilers without KASAN. Since you consider that too
invasive for the stable releases, my current workaround has to suffice.

One side issue that is not solved at all by the patch is
-fsanitize-address-use-after-scope, since that still leads to extreme stack
usage in the kernel. The problem here is that it forces many local variables
into separate stack slots even when they could get reused without
-fsanitize-address-use-after-scope, making it still actively dangerous to run
kernels built with this option.
My workaround in the kernel is now to have that option disabled by default and
only enabled when users explicitly turn it on. I still think it would be nice
to address that in the way I originally suggested, by copying the behavior that
LLVM uses with its variably sized redzone area.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #15 from Arnd Bergmann  ---
(In reply to Arnd Bergmann from comment #14)
> I applied the patches and seem to still get a warning for this

I also just got the one from comment #9 again and found that the reduced test
case is still affected (and not claimed to be fixed by any of the patches, so
that's my fault for not checking).

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #14 from Arnd Bergmann  ---
I applied the patches and seem to still get a warning for this:

$ x86_64-linux-gcc-8.0.1 -Wall -O2 -c nmi_int.c
nmi_int.c: In function 'nmi_setup':
nmi_int.c:43:3: warning: 'memcpy' source argument is the same as destination
[-Wrestrict]
   memcpy(per_cpu(cpu_msrs, cpu).counters,
   ^~~
  per_cpu(cpu_msrs, 0).counters,
  ~~
  sizeof(int) * model->num_counters);
  ~~


typedef unsigned long __kernel_size_t;
extern void * memcpy(void *,const void *,__kernel_size_t);
struct op_msrs {
int *counters;
};
#define for_each_possible_cpu(cpu) for_each_cpu((cpu), cpu_possible_mask)
#define for_each_cpu(cpu, mask)  for ((cpu) = 0; (cpu) < 1; (cpu)++,(void)mask)
extern struct cpumask __cpu_possible_mask;
#define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
#define DEFINE_PER_CPU(type, name) __typeof__(type) name
#define per_cpu_ptr(ptr, cpu)   ({ (void)(cpu); ptr; })
#define raw_cpu_ptr(ptr)per_cpu_ptr(ptr, 0)
#define per_cpu(var, cpu)   (*per_cpu_ptr(&(var), cpu))
extern void *pcpu_base_addr;
extern const unsigned long *pcpu_unit_offsets;
struct op_x86_model_spec {
unsigned intnum_counters;
};
static struct op_x86_model_spec *model;
static DEFINE_PER_CPU(struct op_msrs, cpu_msrs);
int nmi_setup(void)
{
int err = 0;
int cpu;
for_each_possible_cpu(cpu) {
if (!cpu)
continue;
memcpy(per_cpu(cpu_msrs, cpu).counters,
   per_cpu(cpu_msrs, 0).counters,
   sizeof(int) * model->num_counters);
}
return err;
}

In this code, we do copy from a variable onto itself, but only in a dead
branch, here because the for_each_possible_cpu() and per_cpu() macros degrade
to trivial wrappers on an non-SMP build.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[arnd at linaro dot org]

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

--- Comment #27 from Arnd Bergmann  ---
(In reply to Richard Earnshaw from comment #26)
> (In reply to Arnd Bergmann from comment #25)
> 
> > or to apply more force and add the ".arch" to each inline
> > asm individually.
> 
> No, that would not be guaranteed to be supported: and you'd be lying to the
> compiler again.  At the end of each asm block the compiler *could* emit new
> .arch directive to forcibly reset the architecture to what IT thinks it
> should be.

That's fine though: we won't have any invalid instructions outside of the
inline asm, the whole point of setting .arch to a higher arch revision is to
make the inline asm work and avoid the build error from the assembler.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[arnd at linaro dot org]

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

--- Comment #25 from Arnd Bergmann  ---
(In reply to Tamar Christina from comment #24)
> Do you have a repro for this one? compiling the kernel with
> `CFLAGS="march=-armv4t"` doesn't seem to reproduce the original issue.

It needs to be a kernel configuration that enables both an ARMv4-based target
platform (e.g. ARCH_MOXART) and another target platform with ARMv5TE+IWMMXT
(e.g. ARCH_MMP).

> But the scenario should be working without needing to separate out the
> functions, as long as you're in-lining the right direction.

Ah, interesting.

> what would generate the error you're getting is if you're in-lining the
> armv5te code into armv4t which is an actual error
> 
> __attribute__((always_inline, target("arch=armv5te")))
> static inline int do_this (int x)
> {
>   return x*x;
> }
> 
> #pragma GCC target("arch=armv4t")   
> 
> 
> int do_that (int x, int y)
> {
>   return do_this (x - y);
> }
> 
> The compiler only rejects the inlining if you've told it to always inline
> and when the function to be inline's feature bits are not a strict subset of
> the function in which it is to inline

I can't reproduce it here myself now, no idea what I did earlier.

Anyway, since neither the #pragma nor the attribute work on existing
compilers, and making the hack version dependent would be worse,
I don't think we can use that anyway.

The best workaround I see so far is to either move all the affected
inline assembly statements into an external .S file to sidestep the
problem, or to apply more force and add the ".arch" to each inline
asm individually.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[arnd at linaro dot org]

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

--- Comment #23 from Arnd Bergmann  ---
I've done some more testing with '#pragma GCC target("arch=armv5te")' in place,
but ran into another problem:

: note: this is the location of the previous definition
In file included from /git/arm-soc/include/linux/thread_info.h:38,
 from /git/arm-soc/include/asm-generic/current.h:5,
 from ./arch/arm/include/generated/asm/current.h:1,
 from /git/arm-soc/include/linux/sched.h:12,
 from /git/arm-soc/arch/arm/kernel/xscale-cp0.c:14:
/git/arm-soc/arch/arm/kernel/xscale-cp0.c: In function 'dsp_do':
/git/arm-soc/arch/arm/include/asm/thread_info.h:88:35: error: inlining failed
in call to always_inline 'current_thread_info': target specific option mismatch
 static inline struct thread_info *current_thread_info(void)
   ^~~
/git/arm-soc/arch/arm/kernel/xscale-cp0.c:48:18: note: called from here
   dsp_save_state(current_thread_info()->cpu_context.extra);
  ^

I've worked around that now by separating the parts that use inline assembly
into standalone functions with GCC push_options/pop_options around them, so
they are not mixed with normal code that might call an inline function, but
this is getting increasingly ugly.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
I found another false-positive -Wrestrict warning, did a manual reduction. Let
me know if I should better open separate bugs for each test case, or you prefer
to have them all here.

$ aarch64-linux-gcc-8.0.1 -Wall -O2 -c sit.i 
sit.i: In function 'sit_init_net':
sit.i:29:2: warning: 'memcpy' source argument is the same as destination
[-Wrestrict]
  memcpy(&t->ip6rd, &t0->ip6rd, sizeof(t->ip6rd));
  ^~~

void *memcpy(void *, const void *, unsigned long );
struct ip_tunnel_6rd_parm {
int relay_prefix;
int prefixlen;
int relay_prefixlen;
};
struct netdevice {
void *priv;
};
struct ip_tunnel {
struct netdevice *dev;
struct ip_tunnel_6rd_parm ip6rd;
};
struct sit_net {
struct netdevice *fb_tunnel_dev;
};
void ipip6_tunnel_clone_6rd(struct netdevice *dev, struct sit_net *sitn)
{
struct ip_tunnel *t = dev->priv;
if (t->dev == sitn->fb_tunnel_dev)
return;
struct ip_tunnel *t0 = sitn->fb_tunnel_dev->priv;
memcpy(&t->ip6rd, &t0->ip6rd, sizeof(t->ip6rd));
}
int sit_init_net(struct sit_net *sitn, struct netdevice *fb_tunnel_dev) 
{
sitn->fb_tunnel_dev = fb_tunnel_dev;
ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
return 0;
}

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #8 from Arnd Bergmann  ---
Created attachment 43295
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43295&action=edit
linux/drivers/isdn/isdnloop/isdnloop.c, preprocessed, compressed

This is the preprocessed file that showed the funky -Wrestrict warning message:

$ x86_64-linux-gcc-8.0.1 -Wall -O2 isdnloop.i -c -m32 -Wno-pointer-sign
-Wno-unused
In file included from /git/arm-soc/arch/x86/include/asm/page_32.h:35,
 from /git/arm-soc/arch/x86/include/asm/page.h:14,
 from /git/arm-soc/arch/x86/include/asm/thread_info.h:12,
 from /git/arm-soc/include/linux/thread_info.h:38,
 from /git/arm-soc/arch/x86/include/asm/preempt.h:7,
 from /git/arm-soc/include/linux/preempt.h:81,
 from /git/arm-soc/include/linux/spinlock.h:51,
 from /git/arm-soc/include/linux/seqlock.h:36,
 from /git/arm-soc/include/linux/time.h:6,
 from /git/arm-soc/include/linux/stat.h:22,
 from /git/arm-soc/include/linux/module.h:10,
 from /git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:12:
In function 'strcpy',
inlined from 'isdnloop_parse_cmd' at
/git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:900:3,
inlined from 'isdnloop_writecmd' at
/git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:989:5:
/git/arm-soc/include/linux/string.h:437:10: warning: '__builtin_strcpy'
accessing 0 or more bytes at offsets [36, 25] and 446 may overlap up to 0 bytes
at offset [9223372036854775807, -9223372036854775808] [-Wrestrict]
   return __builtin_strcpy(p, q);
  ^~

I did not try to reduce the test case.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[arnd at linaro dot org]

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

--- Comment #19 from Arnd Bergmann  ---
(In reply to Richard Earnshaw from comment #18)
> 
> So you're changing the targetted architecture behind the compilers back.  Ie
> you're lying to it.  Frankly, you deserve to get burnt if you do things like
> that.

Du you have a suggestion on what to do instead?

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[arnd at linaro dot org]

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

--- Comment #16 from Arnd Bergmann  ---
Here is a simplified version of the file in question, to try as standalone:

typedef unsigned int u32;
asm(".arch armv5te\n");
extern int cpuid;
static _Bool cpu_is_xscale_family()
{
/* this code must be compiled to execute on other CPUs, so
   we cannot just use -march=armv5te */
switch (cpuid & 0xe000) {
case 0x69052000: /* Intel XScale 1 */
case 0x69054000: /* Intel XScale 2 */
case 0x69056000: /* Intel XScale 3 */
case 0x56056000: /* Marvell XScale 3 */
case 0x56158000: /* Marvell Mohawk */
return 1;
}
return 0;
}
static int cpu_has_iwmmxt(void)
{
u32 lo;
u32 hi;

/*
 * This sequence is interpreted by the DSP coprocessor as:
 *  mar acc0, %2, %3
 *  mra %0, %1, acc0
 *
 * And by the iWMMXt coprocessor as:
 *  tmcrr   wR0, %2, %3
 *  tmrrc   %0, %1, wR0
 */
__asm__ __volatile__ (
"mcrr   p0, 0, %2, %3, c0\n"
"mrrc   p0, 0, %0, %1, c0\n"
: "=r" (lo), "=r" (hi)
: "r" (0), "r" (0x100));

return !!hi;
}
int xscale_cp0_init(void)
{
/* do not attempt to probe iwmmxt on non-xscale family CPUs */
if (!cpu_is_xscale_family())
return 0;

if (!cpu_has_iwmmxt())
return 0;

/* ... start using iwmmxt */

return 0;
}

$ arm-linux-gnueabi-gcc-7.2.1 -Wall -O2 -c test.c -march=armv4t
# no output

$ arm-linux-gnueabi-gcc-8.0.1 -Wall -O2 -c test.c -march=armv4t
/tmp/ccobFwz5.s: Assembler messages:
/tmp/ccobFwz5.s:34: Error: selected processor does not support `mcrr
p0,0,r0,r3,c0' in ARM mode
/tmp/ccobFwz5.s:35: Error: selected processor does not support `mrrc
p0,0,r3,r2,c0' in ARM mode

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #14 from Arnd Bergmann  ---
It looks like r255468 broke compilation of a couple of files in the Linux
kernel,
which use a top-level statement like

linux/arch/arm/kvm/hyp/banked-sr.c:
__asm__(".arch_extension virt");

linux/arch/arm/kernel/xscale-cp0.c
asm("   .arch armv5te\n");

to allow compilation for a target other than the one specified by with -march=
to the compiler.

I tried using

#if GCC_VERSION >= 80
#pragma GCC target("arch=armv5te")
#else
asm(".arch armv5te\n");
#endif

but that results in a build failure:
/git/arm-soc/arch/arm/kernel/xscale-cp0.c:21: warning: "__ARM_ARCH" redefined
: note: this is the location of the previous definition
/git/arm-soc/arch/arm/kernel/xscale-cp0.c:21: warning: "__ARM_FEATURE_COPROC"
redefined

and presumably would lead to the while file being built for armv5te, possibly
generating instructions that may be invalid for armv4 or armv4t outside of the
inline assembly that is known to be safe.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #6 from Arnd Bergmann  ---
I got one file that produces a rather cryptic warning related to this:

In file included from /git/arm-soc/arch/x86/include/asm/page_32.h:35,
 from /git/arm-soc/arch/x86/include/asm/page.h:14,
 from /git/arm-soc/arch/x86/include/asm/thread_info.h:12,
 from /git/arm-soc/include/linux/thread_info.h:38,
 from /git/arm-soc/arch/x86/include/asm/preempt.h:7,
 from /git/arm-soc/include/linux/preempt.h:81,
 from /git/arm-soc/include/linux/spinlock.h:51,
 from /git/arm-soc/include/linux/seqlock.h:36,
 from /git/arm-soc/include/linux/time.h:6,
 from /git/arm-soc/include/linux/stat.h:22,
 from /git/arm-soc/include/linux/module.h:10,
 from /git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:12:
In function 'strcpy',
inlined from 'isdnloop_parse_cmd' at
/git/arm-soc/drivers/isdn/isdnloop/isdnloop.c:900:3:
/git/arm-soc/include/linux/string.h:437:10: error: '__builtin_strcpy' accessing
0 or more bytes at offsets [36, 25] and 446 may overlap up to 0 bytes at offset
[9223372036854775807, -9223372036854775808] [-Werror=restrict]
   return __builtin_strcpy(p, q);

Not sure if gcc should try to avoid that warning or print something more
helpful in that case. The isdnloop code itself is cryptic enough that I'm not
surprised to see gcc get confused as well, and using strncpy() or strncpy()
instead of strcpy() would avoid the warning and improve the source code.

Possibly gcc should not warn about anything involving 'up to 0 bytes' though
;-)

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
Here are some additional instances in the kernel. I'm currently trying to get a
reliable build first and haven't got a log of all the messages, but there are a
number of changes I did that are related, shutting up the -Wrestrict warning
(some may be -Warray-bounds).

Here are some false-positives:

--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -282,9 +282,7 @@ static void mux_clone(int cpu)
if (!has_mux())
return;

-   memcpy(per_cpu(cpu_msrs, cpu).multiplex,
-  per_cpu(cpu_msrs, 0).multiplex,
-  sizeof(struct op_msr) * model->num_virt_counters);
+   per_cpu(cpu_msrs, cpu).multiplex = per_cpu(cpu_msrs, 0).multiplex;
 }

 #else
@@ -463,6 +461,7 @@ static int nmi_setup(void)
if (!cpu)
continue;

+#ifdef CONFIG_SMP
memcpy(per_cpu(cpu_msrs, cpu).counters,
   per_cpu(cpu_msrs, 0).counters,
   sizeof(struct op_msr) * model->num_counters);
@@ -470,7 +469,7 @@ static int nmi_setup(void)
memcpy(per_cpu(cpu_msrs, cpu).controls,
   per_cpu(cpu_msrs, 0).controls,
   sizeof(struct op_msr) * model->num_controls);
-
+#endif
mux_clone(cpu);
}
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1643,7 +1643,7 @@ static int cfg80211_rtw_scan(struct wiphy *wiphy
spin_lock_bh(&pmlmepriv->lock);
if (request->n_channels == 1) {
for (i = 1;in_channels <= 4) {
for (j =request->n_channels-1;j>= 0;j--)


This one was weird, I suspect my change is incorrect:

diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c
index 941d0930969a..0d322380d952 100644
--- a/drivers/fmc/fmc-fakedev.c
+++ b/drivers/fmc/fmc-fakedev.c
@@ -305,7 +305,7 @@ static int ff_init(void)

/* Replicate the default eeprom for the max number of mezzanines */
for (i = 1; i < FF_MAX_MEZZANINES; i++)
-   memcpy(ff_eeimg[i], ff_eeimg[0], sizeof(ff_eeimg[0]));
+   memcpy(&ff_eeimg[i][0], &ff_eeimg[0][0], sizeof(ff_eeimg[0]));

if (ff_nr_eeprom > ff_nr_dev)
ff_nr_dev = ff_nr_eeprom;

This one seems to be a kernel bug:

--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -129,13 +129,13 @@ int kdbnearsym(unsigned long addr, kdb_symtab_t *symtab)
}
if (i >= ARRAY_SIZE(kdb_name_table)) {
debug_kfree(kdb_name_table[0]);
-   memcpy(kdb_name_table, kdb_name_table+1,
+   memmove(kdb_name_table, kdb_name_table+1,
   sizeof(kdb_name_table[0]) *
   (ARRAY_SIZE(kdb_name_table)-1));
} else {
debug_kfree(knt1);
knt1 = kdb_name_table[i];
-   memcpy(kdb_name_table+i, kdb_name_table+i+1,
+   memmove(kdb_name_table+i, kdb_name_table+i+1,
   sizeof(kdb_name_table[0]) *
   (ARRAY_SIZE(kdb_name_table)-i-1));
}

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
Created attachment 43281
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43281&action=edit
preprocessed simplified sm_sideeffect.c, compressed

I managed to get a standalone testcase now, manually reduced the original
source and then preprocessed. Further automated reduction should be easy now if
necessary.

x86_64-linux-gcc-8.0.1 -c -m32 -o lto-test.o lto-test.i -O2 -flto
-Wno-pointer-sign -fno-strict-aliasing
x86_64-linux-gcc-8.0.1  -fdump-ipa-inline-details   -m32 -r-o sctp.ko
lto-test.o

The part that goes wrong is apparently the '-fdump-ipa-inline-details'.

/git/arm-soc/net/sctp/lto-test.c: In function 'sctp_do_sm':
/git/arm-soc/net/sctp/lto-test.c:120:5: internal compiler error: Segmentation
fault
 int sctp_do_sm(struct net *net, enum sctp_event event_type,
 ^
0xa42b7f crash_signal
/home/arnd/git/gcc/gcc/toplev.c:325
0xaf0659 pp_tree_identifier(pretty_printer*, tree_node*)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:4006
0xaf0966 dump_decl_name
/home/arnd/git/gcc/gcc/tree-pretty-print.c:261
0xaf42ea dump_generic_node(pretty_printer*, tree_node*, int, unsigned long,
bool)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:1826
0xaf769a print_declaration(pretty_printer*, tree_node*, int, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:
0xaf7997 print_generic_decl(_IO_FILE*, tree_node*, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:122
0xb4603a dump_scope_block
/home/arnd/git/gcc/gcc/tree-ssa-live.c:647
0xb471b9 dump_scope_blocks(_IO_FILE*, unsigned long)
/home/arnd/git/gcc/gcc/tree-ssa-live.c:678
0xb471b9 remove_unused_locals()
/home/arnd/git/gcc/gcc/tree-ssa-live.c:870
0x97af44 execute_function_todo
/home/arnd/git/gcc/gcc/passes.c:1972
0x97b8b9 execute_todo
/home/arnd/git/gcc/gcc/passes.c:2048
0x97dac5 execute_one_ipa_transform_pass
/home/arnd/git/gcc/gcc/passes.c:2245
0x97dac5 execute_all_ipa_transforms()
/home/arnd/git/gcc/gcc/passes.c:2281
0x6d681c cgraph_node::expand()
/home/arnd/git/gcc/gcc/cgraphunit.c:2132
0x6d7b38 expand_all_functions
/home/arnd/git/gcc/gcc/cgraphunit.c:2275
0x6d7b38 symbol_table::compile()
/home/arnd/git/gcc/gcc/cgraphunit.c:2624
0x656c51 lto_main()
/home/arnd/git/gcc/gcc/lto/lto.c:3349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/arnd/cross-gcc/bin/x86_64-linux-gcc-8.0.1
returned 1 exit status
compilation terminated.
/home/arnd/cross-gcc/lib/gcc/x86_64-linux/8.0.1/../../../../x86_64-linux/bin/ld:
error: lto-wrapper failed

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Martin Sebor from comment #2)
> (In reply to Arnd Bergmann from comment #0)
> 
> Let me work on this.
> 
> I tested the warning with the kernel but don't recall coming across this
> false positive.  While I retry with the latest, how many of these do you see?

They are fairly rare, I have seen four or five now with randconfig builds over
the last two days. It's possible that there is none in the default config.

[Bug c/84108] [8 Regression] incorrect -Wattributes warning for packed/aligned conflict on struct members

[arnd at linaro dot org]

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Jakub Jelinek from comment #1)
> I vaguely remember the behavior of packed + aligned(N) kept changing in the
> past, some versions of GCC treated it just like packed, others as aligned.
> Is this in the kernel?

Yes. The example I showed corresponds to include/linux/sysv_fs.h, which
probably has very few users, if any. If this was inconsistent in the past, it
may have gone unnoticed. OTOH, there is a compile-time assertion in the code to
ensure that the structure has the right size:

#define __packed2__ __attribute__((packed,aligned(2)))
#define XENIX_NICINOD   100 /* number of inode cache entries */
#define XENIX_NICFREE   100 /* number of free block list chunk entries */
struct xenix_super_block {
__fs16  s_isize; /* index of first data zone */
__fs32  s_fsize __packed2__; /* total number of zones of this
fs */
/* the start of the free block list: */
__fs16  s_nfree;/* number of free blocks in s_free, <=
XENIX_NICFREE */
sysv_zone_t s_free[XENIX_NICFREE]; /* first free block list chunk
*/
/* the cache of free inodes: */
__fs16  s_ninode; /* number of free inodes in s_inode, <=
XENIX_NICINOD */
sysv_ino_t  s_inode[XENIX_NICINOD]; /* some free inodes */
/* locks, not used by Linux: */
chars_flock;/* lock during free block list
manipulation */
chars_ilock;/* lock during inode cache manipulation
*/
chars_fmod; /* super-block modified flag */
chars_ronly;/* flag whether fs is mounted read-only
*/
__fs32  s_time __packed2__; /* time of last super block update
*/
__fs32  s_tfree __packed2__; /* total number of free zones */
__fs16  s_tinode;   /* total number of free inodes */
__fs16  s_dinfo[4]; /* device information ?? */
chars_fname[6]; /* file system volume name */
chars_fpack[6]; /* file system pack name */
chars_clean;/* set to 0x46 when filesystem is
properly unmounted */
chars_fill[371];
s32 s_magic;/* version of file system */
__fs32  s_type; /* type of file system: 1 for 512 byte
blocks
2 for 1024 byte
blocks
3 for 2048 byte
blocks */

};
BUILD_BUG_ON(1024 != sizeof (struct xenix_super_block));

Two other variations of this warning that I ran into are slightly different:
fs/ubifs/ubifs-media.h and include/scsi/libsas.h define a structure with
__attribute__((packed)) and use that structure as a member in another
structure, with that member being marked __attribute__((aligned)). I would hope
that this behavior has never changed.

[Bug c/84108] New: incorrect -Wattributes warning for packed/aligned conflict

[arnd at linaro dot org]

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

Bug ID: 84108
   Summary: incorrect -Wattributes warning for packed/aligned
conflict
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Marking a struct member as both 'packed' and 'aligned()' triggers a warning in
gcc-8:

struct s {
char x;
int y __attribute__((packed, aligned(2)));
int z __attribute__((aligned(2), packed));
} s;

x86_64-linux-gcc-8.0.1 -c -Wall test.c  -O2 -c
test5.c:3:2: warning: ignoring attribute 'aligned' because it conflicts with
attribute 'packed' [-Wattributes]
  int y __attribute__((packed, aligned(2)));
  ^~~
test5.c:4:2: warning: ignoring attribute 'packed' because it conflicts with
attribute 'aligned' [-Wattributes]
  int z __attribute__((aligned(2), packed));
  ^~~

The warning appears to be a mistake, since neither attribute is in fact ignored
here, and both 'y' and 'z' are aligned to two bytes, which matches the gcc
documentation and the behavior of older versions.

[Bug lto/84105] New: [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[arnd at linaro dot org]

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

Bug ID: 84105
   Summary: [8 regression] Segmentation fault in
pp_tree_identifier() during LTO
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I got an ICE while building the linux kernel module net/sctp/sctp.ko with
i386-linux-gcc-8.0.1, currently using r257114. A slightly older gcc-8.0.0
(dated 20180107, exact revision unknown) doesn't have this problem.

  /bin/bash /git/arm-soc/scripts/gcc-ld -fuse-linker-plugin -flto=jobserver
-flto  -fno-strict-aliasing -fno-fat-lto-objects -Wno-attribute-alias
-fwhole-program  -fno-strict-aliasing -fdump-ipa-cgraph
-fdump-ipa-inline-details -fipa-cp-clone -r -m elf_i386 -T
/git/arm-soc/scripts/module-common.lds --build-id  -o net/sctp/sctp.ko
net/sctp/sctp.o net/sctp/sctp.mod.o ;  true
during IPA pass: inline
dump file: net/sctp/sctp.ko.ltrans0.079i.inline
/git/arm-soc/net/sctp/sm_sideeffect.c: In function 'sctp_do_sm':
/git/arm-soc/net/sctp/sm_sideeffect.c:1155:5: internal compiler error:
Segmentation fault
 int sctp_do_sm(struct net *net, enum sctp_event event_type,
 ^
0xa42b7f crash_signal
/home/arnd/git/gcc/gcc/toplev.c:325
0xaf0659 pp_tree_identifier(pretty_printer*, tree_node*)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:4006
0xaf0966 dump_decl_name
/home/arnd/git/gcc/gcc/tree-pretty-print.c:261
0xaf42ea dump_generic_node(pretty_printer*, tree_node*, int, unsigned long,
bool)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:1826
0xaf769a print_declaration(pretty_printer*, tree_node*, int, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:
0xaf7997 print_generic_decl(_IO_FILE*, tree_node*, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:122
0xb4603a dump_scope_block
/home/arnd/git/gcc/gcc/tree-ssa-live.c:647
0xb471b9 dump_scope_blocks(_IO_FILE*, unsigned long)
/home/arnd/git/gcc/gcc/tree-ssa-live.c:678
0xb471b9 remove_unused_locals()
/home/arnd/git/gcc/gcc/tree-ssa-live.c:870
0x97af44 execute_function_todo
/home/arnd/git/gcc/gcc/passes.c:1972
0x97b8b9 execute_todo
/home/arnd/git/gcc/gcc/passes.c:2048
0x97dac5 execute_one_ipa_transform_pass
/home/arnd/git/gcc/gcc/passes.c:2245
0x97dac5 execute_all_ipa_transforms()
/home/arnd/git/gcc/gcc/passes.c:2281
0x6d681c cgraph_node::expand()
/home/arnd/git/gcc/gcc/cgraphunit.c:2132
0x6d7b38 expand_all_functions
/home/arnd/git/gcc/gcc/cgraphunit.c:2275
0x6d7b38 symbol_table::compile()
/home/arnd/git/gcc/gcc/cgraphunit.c:2624
0x656c51 lto_main()
/home/arnd/git/gcc/gcc/lto/lto.c:3349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

I have not been able to create a simple test case for it, but can provide steps
for reproducing, or help test patches. If necessary, I can do a bisection, but
maybe someone can see from the backtrace what is happening, or has a duplicate
bugreport.

>From what I can tell, the ICE is caused by a typedef inside of a function,
moving the typedef outside of the function avoids the problem. See the source
code at:

https://elixir.free-electrons.com/linux/v4.15/source/net/sctp/sm_sideeffect.c#L1172

[Bug middle-end/84095] New: false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

Bug ID: 84095
   Summary: false-positive -Wrestrict warnings for memcpy within
array
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

I see multiple new warnings for correct code in the Linux kernel for code that
copies one array member into other members of the same array, reduced to:

$ cat > test.c << EOF
struct { int i; } a[8];

void f(void)
{
int i;

for (i=1; i <8; i++)
__builtin_memcpy(&a[i], &a[0], sizeof(a[0]));
}
EOF

$ x86_64-linux-gcc-8.0.1 -c -Wall test.c 
test4.c: In function 'f':
test4.c:8:3: warning: '__builtin_memcpy' accessing 4 bytes at offsets 0 and 0
overlaps 4 bytes at offset 0 [-Wrestrict]
   __builtin_memcpy(&a[i], &a[0], sizeof(a[0]));
   ^~~~

[Bug rtl-optimization/84038] [7/8 Regression] powerpc-linux-gcc gets stuck building linux kernel

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Arnd Bergmann  ---
(In reply to Arnd Bergmann from comment #2)
> bisected this one to r244207, and bisected pr83985 to something earlier.

attachment 43241 that jakub created for pr83985 addresses this one as well,
closing as duplicate.

*** This bug has been marked as a duplicate of bug 83985 ***

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[arnd at linaro dot org]

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

--- Comment #7 from Arnd Bergmann  ---
*** Bug 84038 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/84038] [7/8 Regression] powerpc-linux-gcc gets stuck building linux kernel

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #2 from Arnd Bergmann  ---
bisected this one to r244207, and bisected pr83985 to something earlier.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||segher at kernel dot 
crashing.org

--- Comment #3 from Arnd Bergmann  ---
Bisected to "rs6000: Separate shrink-wrapping" (r241065), starting from 7.3.
Adding Segher to Cc. This is not the same commit that caused pr84038 though,
that one started later.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

 CC||arnd at linaro dot org

--- Comment #2 from Arnd Bergmann  ---
Reproduced with gcc-7.3.0 as well.

[Bug target/84038] New: powerpc-linux-gcc gets stuck building linux kernel

[arnd at linaro dot org]

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

Bug ID: 84038
   Summary: powerpc-linux-gcc gets stuck building linux kernel
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 43240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43240&action=edit
linux/kernel/cpu.c, preprocessed and compressed

I tried building all powerpc 'defconfig' kernels with gcc-7.3.0, and got stuck
in mpc866_ads_defconfig while compiling linux/kernel/cpu.c

Build with 'powerpc-linux-gcc-7.3.0 -O2 -c cpu.i'. Passing '-O2
-finline-functions' avoids the problem. 'perf top' during the gcc run shows

  11.30%  cc1 [.] fast_dce
   8.63%  cc1 [.] df_worklist_dataflow
   7.07%  cc1 [.] volatile_refs_p
   6.23%  cc1 [.] prescan_insns_for_dce
   5.94%  cc1 [.] deletable_insn_p
   5.31%  cc1 [.] bitmap_set_bit

I started manually reducing the file. The only other compiler versions I tried
were a 7.2.1 snapshot (same result) and an old 5.4.0 compiler (no problems).

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

--- Comment #15 from Arnd Bergmann  ---
(In reply to rguent...@suse.de from comment #14)

> Would be nice if somebody can bisect it.  It doesn't look like a PRE
> specific issue because there's no relevant PRE changes in the rev. range.
> I can't reproduce the slowdown when comparing 7.1.0 against 7.2.0
> btw, so the regression must occur somewhere between 7.2.0 and now
> (or 7.1.1 got faster for a few revs).

I've checked r251376 (the one I mentioned in comment #11), and confirmed that
this caused the difference between my old 7.1.1 and the current 7.2.1.

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

--- Comment #13 from Arnd Bergmann  ---
Created attachment 43185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43185&action=edit
Linux kernel version of AES algorithm, ported to standalone executable

I've had another look at extracting a test case from the Linux kernel copy of
this code. This now also shows the gcc-7.2.1 specific problem:

$ x86_64-linux-gcc-7.1.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic; time ./aes_generic
real0m9.406s

$ x86_64-linux-gcc-7.1.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic -fno-code-hoisting; time ./aes_generic
real0m8.318s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic; time ./aes_generic
real0m22.151s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 -fsanitize=bounds -fsanitize=object-size
aes_generic.c -o aes_generic -fno-code-hoisting; time ./aes_generic
real0m8.439s

$ x86_64-linux-gcc-7.1.1 -Wall -O2 aes_generic.c -o aes_generic ; time
./aes_generic
real0m3.031s

$ x86_64-linux-gcc-7.1.1 -Wall -O2 aes_generic.c -o aes_generic
-fno-code-hoisting ; time ./aes_generic
real0m2.894s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_generic.c -o aes_generic  ; time
./aes_generic
real0m3.307s

$ x86_64-linux-gcc-7.2.1 -Wall -O2 aes_generic.c -o aes_generic
-fno-code-hoisting ; time ./aes_generic
real0m2.875s

[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher

[arnd at linaro dot org]

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

--- Comment #11 from Arnd Bergmann  ---
Trying out the patch from comment 10 on the original preprocessed source as
attached to pr83356 also shows very noticeable improvements with stack spilling
there:

x86_64-linux-gcc-6.3.1 -Wall -O2 -S ./aes_generic.i  -Wframe-larger-than=10
-fsanitize=bounds -fsanitize=object-size -fno-strict-aliasing ; grep rsp
aes_generic.s | wc -l
/git/arm-soc/crypto/aes_generic.c: In function 'aes_encrypt':
/git/arm-soc/crypto/aes_generic.c:1371:1: warning: the frame size of 48 bytes
is larger than 10 bytes [-Wframe-larger-than=]
4075

x86_64-linux-gcc-7.1.1 -Wall -O2 -S aes_generic.i  -Wframe-larger-than=10
-fsanitize=bounds -fsanitize=object-size -fno-strict-aliasing ; grep rsp
aes_generic.s | wc -l
/git/arm-soc/crypto/aes_generic.c: In function 'aes_encrypt':
/git/arm-soc/crypto/aes_generic.c:1371:1: warning: the frame size of 304 bytes
is larger than 10 bytes [-Wframe-larger-than=]
 }
4141

x86_64-linux-gcc-7.2.1 -Wall -O2 -S aes_generic.i  -Wframe-larger-than=10
-fsanitize=bounds -fsanitize=object-size -fno-strict-aliasing ; grep rsp
aes_generic.s | wc -l
/git/arm-soc/crypto/aes_generic.c: In function 'aes_encrypt':
/git/arm-soc/crypto/aes_generic.c:1371:1: warning: the frame size of 3840 bytes
is larger than 10 bytes [-Wframe-larger-than=]
10351

# same as x86_64-linux-gcc-7.2.1 but with patch from comment 10:
./xgcc -Wall -O2 -S ./aes_generic.i  -Wframe-larger-than=10 -fsanitize=bounds
-fsanitize=object-size -fno-strict-aliasing ; grep rsp aes_generic.s | wc -l 
/git/arm-soc/crypto/aes_generic.c: In function 'aes_encrypt':
/git/arm-soc/crypto/aes_generic.c:1371:1: warning: the frame size of 272 bytes
is larger than 10 bytes [-Wframe-larger-than=]
4739

My interpretation is that there are two distinct issues: both AES
implementations (libressl and linux-kernel) suffer from a 5% to 10% regression
that is triggered by the combination of -ftree-pre and -fcode-hoisting, but
only the kernel implementation suffers from a second issue that Martin Liška
traced back to r251376. This results in another few percents of slowdown in
gcc-7.2.1  and an factor 2.3x slowdown (and corresponding increase in stack
accesses) when -fsanitize=bounds -fsanitize=object-size gets enabled.