On 11/23/2016 12:48 PM, Richard Biener wrote:
On November 23, 2016 8:17:34 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote:
On 11/23/2016 01:29 AM, Richard Biener wrote:
On Wed, Nov 23, 2016 at 1:12 AM, Serge Belyshev
<belys...@depni.sinp.msu.ru> wrote:
My builds for the last couple of days have all been failing in
stage 2
like so:
/home/arth/src/gcc/gcc/config/i386/i386.c: In function ‘rtx_def*
ix86_expand_bui
ltin(tree, rtx, rtx, machine_mode, int)’:
/home/arth/src/gcc/gcc/config/i386/i386.c:38407:18: error: ‘fcn’
may be used uni
nitialized in this function [-Werror=maybe-uninitialized]
emit_insn (fcn (target, accum, wide_reg, mem));
~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anyone else seeing this?
I'm seeing it too. The code is new, but the 'may be used
unitialized'
warning itself is, probably, an instance of the old PR36550.
I have reduced this testcase to:
//------------------------------------------------------------------------
/* { dg-do compile } */
/* { dg-options "-O2 -Wuninitialized" } */
int force_reg (int, int);
int expand_expr_real (int, int);
void f (int);
void ix86_expand_builtin (int fcode, int pmode)
{
int fcn;
int i, addr, masked = 1;
switch (fcode)
{
case 1:
fcn = 1;
masked = 0;
goto s4fma_expand;
case 2:
fcn = 2;
masked = 0;
goto s4fma_expand;
case 4:
{
s4fma_expand:
for (i = 0; i < 4; i++)
expand_expr_real (0, 0);
addr = expand_expr_real (0, 0);
force_reg ((pmode ? 0 : 2), addr);
if (! masked)
f (fcn);
}
}
}
//------------------------------------------------------------------------
It fails with every gcc version down to 3.2 (the oldest one I could
compile on my amd64 box). Note that this testcase is particularly
flaky: recent gccs will not issue a warning if one, for example,
changes
the '2' to '1' in the force_reg() call.
It's an interesting case where the uninit pass has to do sth else
than
looking for a guard on the incoming path to the uninit PHI value
(there's none). But it has to simplify the guard on the use with
values on the edge of the uninit var:
# fcn_1 = PHI <fcn_9(D)(3), 1(14), 2(4)>
# masked_3 = PHI <1(3), 0(14), 0(4)>
s4fma_expand:
...
if (masked_3 == 0)
goto <bb 10>;
else
goto <bb 16>;
<bb 16>:
goto <bb 11> (<L11>);
<bb 10>:
f (fcn_1); [tail call]
that's not something it even tries to do (and this case is
particularly
simple even)
But what left that in the IL? I'd expect jump threading to have
optimized the masked_3 test away completely by isolating the paths
where
it's known to be zero from the path where it's known to be one.
I'm looking at another case where we fail to thread (albeit a lot more
complicated), it seems the backwards threader is not very good in handling
opportunities that require forward propagating of PHI args and DOM requires
excessive iteration (11 DOM passes in this other case...).
Pass it along.
I've got a case here which may need something similar. I've got some
skeleton code that I might be able to beat into shape.
Jeff
