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