https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #16 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #15)
> Well, detecting uninitialized variables is equivalent to generating better
> code. See the following functions. If you want to be able to remove the i =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #18 from Vincent Lefèvre ---
OK, but then, this means that the first sentence of the -Wmaybe-uninitialized
documentation is incorrect. That's probably the "there exists" that is
problematic, because of the possible difference of what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #19 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #18)
> OK, but then, this means that the first sentence of the
> -Wmaybe-uninitialized documentation is incorrect. That's probably the "there
> exists" that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #20 from Marc Glisse ---
(In reply to Vincent Lefèvre from comment #18)
> OK, but then, this means that the first sentence of the
> -Wmaybe-uninitialized documentation is incorrect. That's probably the "there
> exists" that is problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #2 from Vincent Lefèvre ---
Well, the code paths in question do not necessarily exist (you could say the
same thing with -O2, where the function is not inlined: there may be some code
paths for which fn1() doesn't initialize c).
Actua
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Vincent Lefèvre from comment #2)
> > Well, the code paths in question do not necessarily exist (you could say the
> > same thing with -O2, where the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #5 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #3)
> The code path exists in the code,
It exists *only* if fn2() can return 0. But the fact is that in the reality,
this can never happen (with the original non-redu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #6 from Jakub Jelinek ---
How can the compiler know that fn2 never returns 0, without inlining (not in
this case), some attribute (not provided, gcc right now has returns_nonnull
attribute but that is only for pointers) or some interpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #7 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #6)
> How can the compiler know that fn2 never returns 0, without inlining (not in
> this case), some attribute (not provided, gcc right now has returns_nonnull
> attr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Vincent Lefèvre changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #9 from Marc Glisse ---
(In reply to Vincent Lefèvre from comment #8)
> The -Wmaybe-uninitialized rule given in the gcc man page is (for GCC 4.8):
>
> -Wmaybe-uninitialized
> For an automatic variable, if there exists a path fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Vincent Lefèvre from comment #8)
> Concerning the "if it cannot prove the uninitialized paths are not executed
> at run time" part, GCC should be able to prove more things with -O3 than
> w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #12 from Jakub Jelinek ---
Only in your reading of the documentation.
You clearly don't know what you are asking for, even the very common case of
pthread_t th;
if (pthread_create (&th, NULL, tf, NULL))
goto fail;
pthread_join (th,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #13 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #10)
> Now, I agree that ideally, GCC should warn for your last testcase. But I
> guess in that case inlining either doesn't happen or it happens too late, so
> GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #14 from Vincent Lefèvre ---
(In reply to Marc Glisse from comment #9)
> The definition of a function changes with inlining ;-)
It shouldn't: what happens at run time isn't changed by inlining.
> f(&i) is considered as an initializat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #15 from Vincent Lefèvre ---
(In reply to Manuel López-Ibáñez from comment #10)
> Now, I agree that ideally, GCC should warn for your last testcase. But I
> guess in that case inlining either doesn't happen or it happens too late, so
>
20 matches
Mail list logo
