This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/16351] NULL dereference warnings
- From: "manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 07 Aug 2015 18:30:29 +0000
- Subject: [Bug c/16351] NULL dereference warnings
- Auto-submitted: auto-generated
- References: <bug-16351-4 at http dot gcc dot gnu dot org/bugzilla/>
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
variable. I don't see how this code can be refactored to silence the warning
(and the way I understood the warning is by looking at the GCC dumps, which
people will not do).
> Note that in this case, the compiler should be determining that MAP can't be
> NULL and thus linemap_check_ordinary can't return NULL and propagating that
> information. So if we're still getting a warning, then something is wrong
> somewhere.
But how it can do such a thing if the definition of linemap_add were not
available?
(In this case it is, but GCC's IPA is not smart enough to figure it that it
cannot return NULL. The code injected by -f-isolate-paths survives until the
end).
In any case, I don't see how to keep this in -Wall or -Wextra if it breaks GCC
bootstrap. And options that are not enabled by either of those are rarely used
and tend to bit-rot or receive little attention.
Hum, perhaps, we do really need some kind of -Weverything that includes not
every warning, but those that are potentially useful but too noisy to not break
GCC bootstrap.