This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR c/16351 Extend Wnonnull for returns_nonnull
- From: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- To: Trevor Saunders <tbsaunde at tbsaunde dot org>
- Cc: Jeff Law <law at redhat dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Sat, 25 Jul 2015 02:10:37 +0200
- Subject: Re: PR c/16351 Extend Wnonnull for returns_nonnull
- Authentication-results: sourceware.org; auth=none
- References: <CAESRpQAZT7syOqgusqXQEgigUj3UeTfi5iD9CHJKGCAnVfA7Ug at mail dot gmail dot com> <55B127D7 dot 3020202 at redhat dot com> <CAESRpQCe4GTYNqnpeH+TMC3F7G75k1G_cHsQnb-K93sH7et3_Q at mail dot gmail dot com> <55B29270 dot 1030206 at redhat dot com> <CAESRpQBErJnZaiffGugor5ay9YTo3xbkyWQkHqsFKQND6ianCA at mail dot gmail dot com> <20150724231521 dot GB29097 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com>
On 25 July 2015 at 01:15, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> I'd actually expect reasonable cases to be fairly common. For example
I added it to -Wall, I guess we'll see... not sure how many users of
returns_nonnull are out there.
In all your cases there is no reason to prefer NULL rather than, say,
(T*)0xdeadbeef.
Moreover, moving the warning to the ME does not guarantee that no
false positives will be emitted either. It also does not guarantee
that no false positives will be introduced by optimization that did
not exist in the user code. And optimizations may remove trivial true
positives, which seems even worse.
> So at some point we're just talking semantics of words, but I think you
> could make a credible argument that clang doesn't have a true -O0 mode.
> I'm no expert on clang internals, but I think the place they draw a line
> between what is a front end and what is a back is farther back than
> where gcc draws it, but that's basically just a guess.
I think they make a distinction between dataflow analysis and code
transformation. Clang does dataflow analysis on the AST without
changing the code (I think it can even do interprocedural dataflow),
but it leaves the succession of analysis and transformation passes to
LLVM, which does not do warnings. I do not know the precise details of
how all this works, but it seems to work better and faster than what
GCC does right now for Wuninitialized.
Cheers,
Manuel.