public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106559] [10/11/12/13 Regression] Spurious warning -Wformat-truncation (regression from 9) Date: Tue, 16 Aug 2022 16:00:54 +0000 [thread overview] Message-ID: <bug-106559-4-8NqjzlpdIh@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-106559-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106559 Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org Blocks| |85741 --- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> --- The warning triggers because it considers the size of the whole `string' array passed as an argument to the %s directive. It does that because the analysis is unable to determine which array element the argument points to and it's not "smart" enough to see that all the elements are strings of the same length. The output of the -fdump-tree-strlen option below helps see what's gooing on (the numbers next to each Result: show the minimum, maximum, likely, and unlikely amount of output produced by the directive, with the corresponding running totals in parentheses). The problem can be reduced to a missed optimization opportunity in the test following test case: the condition in each iteration of the loop is false so the loop can be optimized away, but because of the incomplete analysis above it is not. void f (void) { static const char string[16][3]={ "01","02","03","04","05","06","07","08", "09","10","11","12","13","14","15","16"}; for(unsigned int i=0; i<16; ++i) if (__builtin_strlen (string[i]) != 2) __builtin_abort (); } Short of improving the strlen optimization the warning could also be suppressed by considering the cast in the assignment `_2 = (const char[3] *) ivtmp.11_15;' and using the size of the array as the upper bound on the length of the string. (This wouldn't be safe for the optimization.) Until this is fixed in GCC, the warning can be suppressed and the emitted code improved by asserting in each iteration that the length of the string is (at most) two, like so: if (__builtin_strlen (string[i]) != 2) __builtin_unreachable (); pr106559.c:11: __builtin_snprintf: objsize = 64, fmtstr = "%u (%s): %8x" Directive 1 at offset 0: "%u" Result: 1, 2, 2, 2 (1, 2, 2, 2) Directive 2 at offset 2: " (", length = 2 Result: 2, 2, 2, 2 (3, 4, 4, 4) Directive 3 at offset 4: "%s" Result: 0, 47, 47, 9223372036854775807 (3, 51, 51, -9223372036854775805) Directive 4 at offset 6: "): ", length = 5 Result: 5, 5, 5, 5 (8, 56, 56, -9223372036854775800) Directive 5 at offset 11: "%8x" Result: 8, 8, 8, 8 (16, 64, 64, -9223372036854775792) Directive 6 at offset 14: "", length = 1 pr106559.c: In function ‘f’: pr106559.c:11:61: warning: ‘__builtin_snprintf’ output may be truncated before the last format character [-Wformat-truncation=] 11 | __builtin_snprintf(buffer,sizeof(buffer),"%u (%s): %8x", | ^ pr106559.c:11:5: note: ‘__builtin_snprintf’ output between 17 and 65 bytes into a destination of size 64 11 | __builtin_snprintf(buffer,sizeof(buffer),"%u (%s): %8x", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12 | i,string[i],number[i]); | ~~~~~~~~~~~~~~~~~~~~~~ void f () { unsigned long ivtmp.11; unsigned long ivtmp.5; unsigned int i; static const char string[16][3] = {"01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12", "13", "14", "15", "16"}; unsigned int _1; const char[3] * _2; unsigned int _18; <bb 2> [local count: 63136016]: ivtmp.11_17 = (unsigned long) &string; <bb 3> [local count: 1010605809]: # ivtmp.5_13 = PHI <ivtmp.5_14(5), 0(2)> # ivtmp.11_15 = PHI <ivtmp.11_16(5), ivtmp.11_17(2)> _18 = (unsigned int) ivtmp.5_13; _1 = MEM[(unsigned int *)&number + ivtmp.5_13 * 4]; _2 = (const char[3] *) ivtmp.11_15; <<< cast not considered __builtin_snprintf (&buffer, 64, "%u (%s): %8x", _18, _2, _1); <<< warning here for _2 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 [Bug 85741] [meta-bug] bogus/missing -Wformat-overflow
next prev parent reply other threads:[~2022-08-16 16:00 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-08 15:10 [Bug middle-end/106559] New: Spurious warning format-truncation " phdiv at fastmail dot fm 2022-08-09 7:37 ` [Bug tree-optimization/106559] [10/11/12/13 Regression] Spurious warning -Wformat-truncation " rguenth at gcc dot gnu.org 2022-08-16 16:00 ` msebor at gcc dot gnu.org [this message] 2022-12-14 2:28 ` pinskia at gcc dot gnu.org 2023-07-07 10:43 ` [Bug tree-optimization/106559] [11/12/13/14 " rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-106559-4-8NqjzlpdIh@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).