public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/58698] [4.7/4.8/4.9 Regression] Spurious "may be used unitialized" warning when compiling with -Os Date: Mon, 14 Oct 2013 16:50:00 -0000 [thread overview] Message-ID: <bug-58698-4-oliT1s2Qms@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-58698-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58698 Jeffrey A. Law <law at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com --- Comment #7 from Jeffrey A. Law <law at redhat dot com> --- This is a result of jump threading being throttled at -Os. When optimizing for size, we will not thread through a block with side effects that has more than one predecessor. Such blocks have to be duplicated to isolate the optimizable path through the CFG. The duplication can obviously contribute to code size increases. In this particular example we have a CFG path we can optimize. bb52->bb95->bb198 (gdb) p debug_bb_n (52) <bb 52>: _173 = (sizetype) _170; _174 = buf_111 + _173; fcd_err (4, "raid.c:382: WARNING: RAID device name \'%.*s\' too long\n", _171, _174); goto <bb 95>; $63 = (basic_block_def *) 0x7ffff7d7f208 (gdb) p debug_bb_n (95) <bb 95>: # _200 = PHI <-1(52), -1(68), 0(69), 1(71), -1(72), 1(92), ret_201(93), -1(94)> # array_380 = PHI <array_431(52), _209(68), _209(69), _209(71), _209(72), array_427(92), array_416(93), array_416(94)> uuid ={v} {CLOBBER}; if (_200 < 0) goto <bb 198>; else goto <bb 96>; $64 = (basic_block_def *) 0x7ffff7d7f888 (gdb) p debug_bb_n (198) <bb 198>: goto <bb 160>; So normally we'd duplicate bb95 so that we can optimize the path 52->95->198 since on that path we know where bb95 will go. With jump threading throttled because bb95 has > 1 pred and statements with side effects (uuid = ...), the path is not optimized as stays as shown above. Thus, the uninitialized warning analysis has to consider that the path 52->95->96 may be traversed and if that path is followed, it'll use "array".
next prev parent reply other threads:[~2013-10-14 16:50 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-10-12 3:09 [Bug c/58698] New: " arequipeno at gmail dot com 2013-10-12 3:10 ` [Bug c/58698] " arequipeno at gmail dot com 2013-10-12 3:11 ` arequipeno at gmail dot com 2013-10-12 3:13 ` arequipeno at gmail dot com 2013-10-12 19:50 ` [Bug tree-optimization/58698] " pinskia at gcc dot gnu.org 2013-10-14 9:05 ` [Bug tree-optimization/58698] [4.7/4.8/4.9 Regression] " rguenth at gcc dot gnu.org 2013-10-14 16:50 ` law at redhat dot com [this message] 2013-11-05 15:00 ` rguenth at gcc dot gnu.org 2013-11-19 22:18 ` law at redhat dot com
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-58698-4-oliT1s2Qms@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).