public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds
@ 2023-06-01 10:12 arnd at linaro dot org
2023-06-01 13:32 ` [Bug gcov-profile/110074] code bloat with -fprofile-arcs " pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: arnd at linaro dot org @ 2023-06-01 10:12 UTC (permalink / raw)
To: 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug gcov-profile/110074] code bloat with -fprofile-arcs + -fsanitize=bounds
2023-06-01 10:12 [Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds arnd at linaro dot org
@ 2023-06-01 13:32 ` pinskia at gcc dot gnu.org
2023-06-01 13:49 ` [Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds pinskia at gcc dot gnu.org
2023-06-02 7:51 ` rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-01 13:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|sanitizer |gcov-profile
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>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
Well in the case of GCC, it is the order of sanitizer and profile-arcs is the
opposite of clang/LLVM's. That is the issue is we need not to generate
profile-arcs for code added by the sanitizer.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds
2023-06-01 10:12 [Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds arnd at linaro dot org
2023-06-01 13:32 ` [Bug gcov-profile/110074] code bloat with -fprofile-arcs " pinskia at gcc dot gnu.org
@ 2023-06-01 13:49 ` pinskia at gcc dot gnu.org
2023-06-02 7:51 ` rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-01 13:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-06-01
Ever confirmed|0 |1
Summary|code bloat with |-fprofile-arcs profiles
|-fprofile-arcs + |arcs generated by
|-fsanitize=bounds |-fsanitize=bounds
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Simplified example:
```
int array[104];
int f(int t)
{
return array[t];
}
```
Compile this at -fprofile-arcs -O2 -fsanitize=bounds and in .optimized we
have:
```
PROF_edge_counter_5 = __gcov0._Z1fi[0];
PROF_edge_counter_6 = PROF_edge_counter_5 + 1;
__gcov0._Z1fi[0] = PROF_edge_counter_6;
# DEBUG BEGIN_STMT
_11 = (sizetype) t_1(D);
if (_11 >= 104)
goto <bb 3>; [0.05%]
else
goto <bb 4>; [99.95%]
<bb 3> [local count: 536864]:
_12 = (unsigned long) t_1(D);
__builtin___ubsan_handle_out_of_bounds (&*.Lubsan_data0, _12);
<bb 4> [local count: 1073741824]:
PROF_edge_counter_7 = __gcov0._Z1fi[1];
PROF_edge_counter_8 = PROF_edge_counter_7 + 1;
__gcov0._Z1fi[1] = PROF_edge_counter_8;
_4 = array[t_1(D)];
```
But we do really need to profile that arc?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds
2023-06-01 10:12 [Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds arnd at linaro dot org
2023-06-01 13:32 ` [Bug gcov-profile/110074] code bloat with -fprofile-arcs " pinskia at gcc dot gnu.org
2023-06-01 13:49 ` [Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds pinskia at gcc dot gnu.org
@ 2023-06-02 7:51 ` rguenth at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-06-02 7:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The profiling code cannot tell that apart, and yes, with sanitize recover we
should. In principle we could detect all sanitizer calls to be in cold paths
during profile estimation and have a profile instrumentation mode ignoring
statically predicted (with good quality) branches. But that would mean to
build a shadow CFG to compute the counter inserts then.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-06-02 7:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-01 10:12 [Bug sanitizer/110074] New: code bloat with -fprofile-args + -fsanitize=bounds arnd at linaro dot org
2023-06-01 13:32 ` [Bug gcov-profile/110074] code bloat with -fprofile-arcs " pinskia at gcc dot gnu.org
2023-06-01 13:49 ` [Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds pinskia at gcc dot gnu.org
2023-06-02 7:51 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).