https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2022-03-31
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. At -O2 we end up with
int main ()
{
<bb 2> [local count: 1073741824]:
[t.c:4:2] # DEBUG BEGIN_STMT
[t.c:5:2] # DEBUG BEGIN_STMT
[t.c:5:8] # DEBUG l_165 => 128
[t.c:6:2] # DEBUG BEGIN_STMT
[t.c:6:10] # DEBUG l_144 => 0
[t.c:7:2] # DEBUG BEGIN_STMT
[t.c:7:4] a = 1;
[<built-in>:0:0] return 0;
}
while -O1 has
int main ()
{
<bb 2> [local count: 1073741824]:
[t.c:4:2] # DEBUG BEGIN_STMT
[t.c:5:2] # DEBUG BEGIN_STMT
[t.c:5:8] # DEBUG l_165 => 128
[t.c:6:2] # DEBUG BEGIN_STMT
[t.c:7:2] # DEBUG BEGIN_STMT
[t.c:7:4] a = 1;
[<built-in>:0:0] return 0;
with -O1 we do not inline b() but instead CCP uses value-range info to
determine
that l_144 cannot be 128 and thus the call to b() is DCEd before it is
inlined. So indeed at -O1 we do not know the value of l_144, we only know
that it cannot be 128.
Not sure what we can do about the missing debug info - IIRC we cannot
encode in DWARF that l_144 has the value of 'b()' (which is discovered
to have no side-effects besides the return value).
