https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Martin Sebor changed:
What|Removed |Added
CC||matthew at wil dot cx
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #9 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #8)
> You're right, the test cases aren't equivalent, or meant to be. What I want
> to highlight is that in the test case in comment #6, in g() and other
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #8 from Martin Sebor ---
You're right, the test cases aren't equivalent, or meant to be. What I want to
highlight is that in the test case in comment #6, in g() and other similar ones
like it the warning is most likely going to be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> The problem is that when the address of a variable escapes, because GCC
> doesn't track when, when the function from which it escapes calls another
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2016-08-23 00:00:00 |2021-3-26
Known to fail|7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
--- Comment #5 from Manuel López-Ibáñez ---
Even simpler:
int f (int*);
int g(void);
int foo (void)
{
int b;
if (g() && f ())
return 0;
return b;
}
we have:
# .MEM_7 = VDEF <.MEM_6(D)>
# USE = nonlocal null { D.1912 }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60488
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
