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


  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: link
Be 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).