https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #58 from Martin Sebor ---
It's fine with me, just as long as we don't lose track of any outstanding bugs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #57 from Eric Gallager ---
(In reply to Martin Sebor from comment #56)
> I'd say any warning option with more than just a handful of pr's against it
> would benefit from having a meta-bug.
On second thought I think actually a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #56 from Martin Sebor ---
I'd say any warning option with more than just a handful of pr's against it
would benefit from having a meta-bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #54 from Martin Sebor ---
(In reply to janus from comment #53)
Unfortunately, it isn't. The warning depends on actually dereferencing the
null pointer (i.e., trying to access the object it points to) and passing the
argument in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #52 from Martin Sebor ---
-Wnull-dereference is a language-independent option (it works for C, C++, and
should work for all other languages).
But this bug isn't the right forum to discuss general GCC usage questions (such
as why -Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #51 from Tim Ruehsen ---
(In reply to Martin Sebor from comment #50)
> Yes, -Wnull-dereference is only in GCC 6 and later. -Wnonnull is in 5 and
> prior but it does only a superficial job of checking (it only detects null
> pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #50 from Martin Sebor ---
Yes, -Wnull-dereference is only in GCC 6 and later. -Wnonnull is in 5 and
prior but it does only a superficial job of checking (it only detects null
pointer constants). in GCC 7, -Wnonnull does a better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #49 from Jon Grant ---
(In reply to Martin Sebor from comment #48)
> Send a check to Manuel ;) The feature is available under the
> -Wnull-dereference option (see comment 31). Unfortunately, due to false
> positives, the option was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #48 from Martin Sebor ---
Send a check to Manuel ;) The feature is available under the
-Wnull-dereference option (see comment 31). Unfortunately, due to false
positives, the option was removed from -Wall in a subsequent commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #47 from Jon Grant ---
I'm happy to pay a 400 USD bug bounty to contributors who introduce this
feature in GCC. Let's get this feature in! :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #45 from Jon Grant ---
(In reply to Manuel López-Ibáñez from comment #39)
> (In reply to David Binderman from comment #38)
> > It could even be the case that the "potential NULL" code gets
> > put into some backwater flag away from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #44 from Jeffrey A. Law law at redhat dot com ---
Duh, I should have remembered that we had returns_nonnull because I wrote a
dataflow pass to find any NULLs that flow to such statements :-)
The pieces that are missing are tagging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #40 from Jon Grant jg at jguk dot org ---
(In reply to Manuel López-Ibáñez from comment #35)
snip
which means that there is a path through which a null pointer could be
potentially dereferenced. However, this actually cannot happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #41 from Jeffrey A. Law law at redhat dot com ---
Actually I think we want the concept of never returns NULL, both as an
attribute and as a property the compiler can discover by analysis. Given that
property on the return value, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #42 from Tim Ruehsen tim.ruehsen at gmx dot de ---
(In reply to Jeffrey A. Law from comment #41)
Actually I think we want the concept of never returns NULL, both as an
attribute and as a property the compiler can discover by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #43 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Tim Ruehsen from comment #42)
(In reply to Jeffrey A. Law from comment #41)
Actually I think we want the concept of never returns NULL, both as an
attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #33 from David Binderman dcb314 at hotmail dot com ---
I found that using -g -O2 -Wall didn't enable this warning.
Some of the documentation says it does.
I can see that this new warning isn't ready for prime time yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #34 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to David Binderman from comment #33)
I found that using -g -O2 -Wall didn't enable this warning.
Some of the documentation says it does.
Ops, you are right. I used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #38 from David Binderman dcb314 at hotmail dot com ---
(In reply to Manuel López-Ibáñez from comment #35)
I fear this case might be quite common and lead to many false positives that
are then quite hard to understand due to the poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #35 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #34)
(In reply to David Binderman from comment #33)
I found that using -g -O2 -Wall didn't enable this warning.
Some of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #37 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #36)
It's no different maybe uninitialized warnings.
Well, one can silence uninitialized warnings by simply initializing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #36 from Jeffrey A. Law law at redhat dot com ---
But those are *precisely* the ones that need deep investigation. That
investigation may find a real bug, it may find a relatively simple missed
optimization, complex missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #39 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to David Binderman from comment #38)
It could even be the case that the potential NULL code gets
put into some backwater flag away from -Wall, and, after a suitable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #31 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Author: manu
Date: Wed Aug 5 17:36:29 2015
New Revision: 226640
URL: https://gcc.gnu.org/viewcvs?rev=226640root=gccview=rev
Log:
gcc/ChangeLog:
2015-08-05 Manuel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #32 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
The NULL dereference warnings originally requested should be working in GCC 6
(unless we find some issue and the patch gets reverted). However, the original
patch by Jeff also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Jon Grant jg at jguk dot org changed:
What|Removed |Added
CC||jg at jguk dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
pmatos at gcc dot gnu.org changed:
What|Removed |Added
CC||pmatos at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #24 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Tim Ruehsen from comment #23)
The requested warning is an absolutely must-have (enabled by default).
Seeing this bug open since 2004 is... well ... I have no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #26 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to pmatos from comment #25)
(In reply to Manuel López-Ibáñez from comment #24)
I can give you many examples of old must-have bugs that are easy to fix,
but simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #29 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Tim Ruehsen from comment #28)
I far as I can read, not a patch is missing. A review + commit is missing.
How can you ask for more developers (=patches) when the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #28 from Tim Ruehsen tim.ruehsen at gmx dot de ---
I far as I can read, not a patch is missing. A review + commit is missing.
How can you ask for more developers (=patches) when the work is ignored ?
Don't get me wrong, I just try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #27 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #26)
A good place to start is
https://gcc.gnu.org/bugzilla/buglist.
cgi?keywords=easyhacklist_id=116934order=bug_idquery_format=advanced
Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Tim Ruehsen tim.ruehsen at gmx dot de changed:
What|Removed |Added
CC||tim.ruehsen at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #21 from Jeffrey A. Law law at redhat dot com ---
It's annoying, but I suspect others see this as so low priority as not to care.
As for just committing my patch, I could make an argument that I ought to be
able to do that, but we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #22 from Marc Glisse glisse at gcc dot gnu.org ---
There were some comments by Florian:
https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00149.html
I don't think the patch was ever pinged during stage 1, worth another try...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #19 from Jeffrey A. Law law at redhat dot com ---
Nobody ever reviewed the changes :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #19)
Nobody ever reviewed the changes :(
If precisely you cannot get someone to review your patches, the lack of
manpower in GCC is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #16)
Created attachment 31928 [details]
Work-In-Progress patch
Jeff, what happened with this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||dcb314 at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #16 from Jeffrey A. Law law at redhat dot com ---
Created attachment 31928
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31928action=edit
Work-In-Progress patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #15 from Jeffrey A. Law law at redhat dot com ---
I expect it will be in GCC 4.9. It's a wrap-up item for
-fisolate-erroneous-paths.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
hannes hannes at stressinduktion dot org changed:
What|Removed |Added
CC||hannes at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #12 from Jeffrey A. Law law at redhat dot com ---
gimple-ssa-isolate-paths.c has the necessary logic to catch a lot of this kind
of stuff now. From what I can tell, it would catch everything properly in the
attached testcase.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #13 from Jeffrey A. Law law at redhat dot com ---
Just adding a quick warning_at at the points where we optimize erroneous uses
of NULL I get:
j.c: In function 'test1':
j.c:10:9: warning: Erroneous NULL pointer use (explicit)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Paulo J. Matos Paulo.Matos at csr dot com changed:
What|Removed |Added
CC||Paulo.Matos at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-13 16:22 ---
*** Bug 30368 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From walles at mailblocks dot com 2004-12-07 12:04
---
Bug 18854 deals with *potential* NULL pointer dereferences, while this one
mentions only *confirmed* NULL pointer dereferences, i.e:
1 #include stdlib.h
2 int main(int argc, char *argv[]) {
3 volatile char
--- Additional Comments From phython at gcc dot gnu dot org 2004-12-07
16:08 ---
I'd probably leave them as the same bug for now. Neither are being fixed for
4.0 so I don't think it's a problem having one bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-06
14:19 ---
*** Bug 18854 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
54 matches
Mail list logo
