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 meta-bu
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
S
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
--- C
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 c
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 job
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 (r226
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 #46
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 -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #44 from Jeffrey A. Law ---
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 functions with that attr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #43 from Manuel López-Ibáñez ---
(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 and as a property the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #42 from Tim Ruehsen ---
(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 analysis. Given
> that propert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #41 from Jeffrey A. Law ---
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 can be propagated into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #40 from Jon Grant ---
(In reply to Manuel López-Ibáñez from comment #35)
> which means that there is a path through which a null pointer could be
> potentially dereferenced. However, this actually cannot happen because
> linemap_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #39 from Manuel López-Ibáñez ---
(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 period
> of more tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #38 from David Binderman ---
(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 location info in the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #37 from Manuel López-Ibáñez ---
(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
variable. I don't see how this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #36 from Jeffrey A. Law ---
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 optimizations or poor APIs.
It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #35 from Manuel López-Ibáñez ---
(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 documentation says it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #34 from Manuel López-Ibáñez ---
(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 the wrong EnabledBy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #33 from David Binderman ---
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 #32 from Manuel López-Ibáñez ---
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 used the nonnull attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #31 from Manuel López-Ibáñez ---
Author: manu
Date: Wed Aug 5 17:36:29 2015
New Revision: 226640
URL: https://gcc.gnu.org/viewcvs?rev=226640&root=gcc&view=rev
Log:
gcc/ChangeLog:
2015-08-05 Manuel López-Ibáñez
Jeff L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Jon Grant changed:
What|Removed |Added
CC||jg at jguk dot org
--- Comment #30 from Jon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #29 from Manuel López-Ibáñez ---
(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 work is ignored ?
> Don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #28 from Tim Ruehsen ---
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 understand how this should
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=easyhack&list_id=116934&order=bug_id&query_format=advanced
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #26 from Manuel López-Ibáñez ---
(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 there is no on
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 ---
(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 words.
GCC needs lots of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Tim Ruehsen changed:
What|Removed |Added
CC||tim.ruehsen at gmx dot de
--- Comment #23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #22 from Marc Glisse ---
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 #21 from Jeffrey A. Law ---
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 (the project) make a con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #20 from Manuel López-Ibáñez ---
(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 becoming truly desperate,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #19 from Jeffrey A. Law ---
Nobody ever reviewed the changes :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #18 from Manuel López-Ibáñez ---
(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 changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #16 from Jeffrey A. Law ---
Created attachment 31928
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31928&action=edit
Work-In-Progress patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #15 from Jeffrey A. Law ---
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 changed:
What|Removed |Added
CC||hannes at stressinduktion dot
org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #13 from Jeffrey A. Law ---
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)
[enabled by default]
s->bar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #12 from Jeffrey A. Law ---
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
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=16351
Paulo J. Matos changed:
What|Removed |Added
CC||Paulo.Matos at csr dot com
--- Comment #
--- 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 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 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
2 int main(int argc, char *argv[]) {
3 volatile char *monkey
--- 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
