------- Comment #8 from manu at gcc dot gnu dot org 2008-01-20 16:06 -------
(In reply to comment #7)
> (In reply to comment #6)
>
> > Sorry, I don't have any of those trees left. But if I ever come to
> > revisit those two bugs I'll make sure it fixes this bogus warning.
>
> If you can give me some hints about where to start, I do have the
> patched tree around on one of my machines, so I might make a stab at
> fixing this. I'm not a seasoned GCC hacker but willing to learn. ;-)
If you have questions about GCC development they will be more visible on
[EMAIL PROTECTED] than in this bug report.
A "may be" uninitialized warning is given when execute_late_warn_uninitialized
finds an input to a PHI node that is SSA_NAME with an empty definition. This is
marked as in the output of -fdump-tree-* as, for example,
# BLOCK 14 freq:596
# PRED: 7 [14.3%] (exec) 8 [100.0%] (fallthru,exec) 9 [100.0%]
(fallthru,exec) 10 [100.0%] (fallthru,exec) 11 [100.0%] (fallthru,exec) 12
[100.0%] (fallthru,exe\
c) 13 [100.0%] (fallthru,exec)
# aregD.1596_1 = PHI <aregD.1596_26(D)(7), aregD.1596_31(8),
aregD.1596_38(9), aregD.1596_44(10), aregD.1596_51(11), aregD.1596_57(12),
aregD.1596_64(13)>
<L11>:;
The aregD.1596_26(D)(7) means that if we entered this BB from BB 7, then the
value of the variable is uninitialized.
In BB 7 we have:
# BLOCK 7 freq:596
# PRED: 6 [50.0%] (true,exec)
switch (val.0D.1608_22)
{
case 26: goto <L5>;
case 27: goto <L6>;
case 28: goto <L7>;
case 29: goto <L8>;
case 30: goto <L9>;
case 31: goto <L10>;
default : goto <L11>;
}
# SUCC: 8 [14.3%] (exec) 9 [14.3%] (exec) 10 [14.3%] (exec) 11 [14.3%]
(exec) 12 [14.3%] (exec) 13 [14.3%] (exec) 14 [14.3%] (exec)
The 'default' case jumps directly into BB 14 above and thus creates the extra
input to the PHI node which is detected by the execute_late_warn_uninitialized
pass.
If you can manage to convince GCC to not create that default case, then I think
the PHI node won't contain any input with (D) and the warning won't be emitted.
Now, if I understood Richard correctly, PR14495 is about not creating the
default case in general by using VRP information. However, even if you fix
that, there is another bug in VRP (PR30317) that doesn't handle the kind of
comparisons that appear in this testcase.
I don't think those are trivial bugs, but if you still want to give it a try,
to test that you fixed PR14495 you can modify your testcase to use "if" instead
of a switch:
if ((val >= 26)) && (val <= 31))
{
unsigned int areg;
if (val == 26)
areg = xreg = (xreg & 0xff00) | (bval & 0xff);
else if (val == 27)
areg = xreg =
(xreg & 0xff) | ((bval << 8) & 0xff00);
else if (val == 28)
areg = yreg = (yreg & 0xff00) | (bval & 0xff);
else if (val == 29)
areg = yreg =
(yreg & 0xff) | ((bval << 8) & 0xff00);
else if (val == 30)
areg = zreg = (zreg & 0xff00) | (bval & 0xff);
else if (val == 31)
areg = zreg =
(zreg & 0xff) | ((bval << 8) & 0xff00);
disp_print_addr_reg (val, areg);
}
But this still gets a warning because you need to fix PR30317 first. If you
modify the above slightly, VRP works and you don't get the warning:
if ((val >= 26))
if ((val <= 31))
{
unsigned int areg;
if (val == 26)
areg = xreg = (xreg & 0xff00) | (bval & 0xff);
else if (val == 27)
areg = xreg =
(xreg & 0xff) | ((bval << 8) & 0xff00);
else if (val == 28)
areg = yreg = (yreg & 0xff00) | (bval & 0xff);
else if (val == 29)
areg = yreg =
(yreg & 0xff) | ((bval << 8) & 0xff00);
else if (val == 30)
areg = zreg = (zreg & 0xff00) | (bval & 0xff);
else if (val == 31)
areg = zreg =
(zreg & 0xff) | ((bval << 8) & 0xff00);
disp_print_addr_reg (val, areg);
}
Good luck!
--
manu at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2008-01-15 10:49:47 |2008-01-20 16:06:48
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34793
