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
