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).