[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #9 from thutt at vmware dot com 2008-12-23 15:44 --- (In reply to comment #1) The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. Witeness the last sentence. If this is the case, then might it not be better for the diagnostic to be an error rather than a warning? If it's a warning that is not even printed at the standard level of warnings, then it could be easily argued that the compiler is generating bad code. In other words, if a parameter does not meet a required precondition, then the compiler should issue an error always. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-04-25 20:52 --- *** This bug has been marked as a duplicate of 17308 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-01 22:01 --- nonnull attribute to the function says the function's argument is non null at the time we enter the function so assuming that is correct. Also this is documented this way: nonnull (arg-index, ...) The nonnull attribute specifies that some function parameters should be non-null pointers. For instance, the declaration: extern void * my_memcpy (void *dest, const void *src, size_t len) __attribute__((nonnull (1, 2))); causes the compiler to check that, in calls to my_memcpy, arguments dest and src are non-null. If the compiler determines that a null pointer is passed in an argument slot marked as non-null, and the -Wnonnull option is enabled, a warning is issued. The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null. Witeness the last sentence. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #2 from madcoder at debian dot org 2006-12-01 22:45 ---
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo' function from the bug report.
When you do :
size_t i;
// ...
if (i = 0) { ...
if (i 0) { ...
gcc issues a warning to tell me that I'm doing a test that will always be true
(or always be false). I'd just like to have the same when I've specified that a
parameter is nonnull and that I nontheless tries to see if it's NULL or not.
You're not answering to what I ask, I've read the documentation, and I've
already acknowledged that gcc optimizations in presence of the nonnull
attribute are legitimate.
--
madcoder at debian dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-01 22:49 ---
(In reply to comment #2)
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo' function from the bug report.
When you do :
size_t i;
// ...
if (i = 0) { ...
if (i 0) { ...
And this optimization happens way after we are done parsing so ...
I don't think a warning is the right thing in this case because the developer
should have read the documention and it is harder to give a warning in this
case really as this optimization is done currently only in the VRP so we don't
know if it is from
*a = 1;
if (!a)
...
of just
from nonnull.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #4 from zackw at panix dot com 2006-12-02 05:19 --- Andrew, please don't close enhancement requests WONTFIX because you think they're too hard to implement. There is no harm in leaving them open in case someone decides that it's not too hard and they're going to code it. Also, please don't insult our users by implying they didn't read the documentation, especially when the immediately previous message demonstrates beyond question that they did. Actually, just quit insulting the users. OK? -- zackw at panix dot com changed: What|Removed |Added CC||zackw at panix dot com Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-02 05:52 ---
The main issue I have emitting a warning here is that it will produce a bunch
of false positives for an example:
static int f(int *a)
{
if (a)
return *a;
return -1;
}
int g(int *a, int c) __attribute__((nonnull(1) ));
int g(int *a, int c)
{
if (c)
return f(a);
return -1;
}
int h(int *a, int c)
{
if (c)
return f(a);
return -1;
}
Or even f is a define:
#define f(a) ({int *b_ = a; int t = -1; if(b_) t = *b_; t;})
Also we don't want to warn for:
int g(int *a, int c) __attribute__((nonnull(1) ));
int *x;
int g(int *a, int c)
{
if (!c) a = x
if (a) return *a;
return c;
}
This shows how very fragile this warning will have to be to be able to not to
warn in those cases. The unsigned warning is very fragile when it comes to
macros (and templates) also but it is not as fragile as this warning as it is
not flow sensative.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #6 from zackw at panix dot com 2006-12-02 06:00 --- Subject: Re: __attribute__((nonull(...))) and silent optimizations Well, it's just like 'may be used uninitialized' false positives, isn't it? The warning shouldn't issue from the VRP pass, we should have some kind of data-flow-dependent warning pass that operates really, really early (though still on language-independent IL) so that we can have nice predictable rules about what it will and will not catch... Anyway that's how I'd do it. Which I am not volunteering to do, mind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
[Bug c/30043] __attribute__((nonull(...))) and silent optimizations
--- Comment #7 from zackw at panix dot com 2006-12-02 06:04 --- Subject: Re: __attribute__((nonull(...))) and silent optimizations Also: my main concern here is not the technical details of the feature but my dislike for your tendency to blow off bug reports that you think are bogus and insult the users who reported them. That's not the public face the project should present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30043
