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
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
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
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
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()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #7 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #13 from Marc Glisse glisse at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #14 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #15 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(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
20 matches
Mail list logo
