The patch series is currently under review:
[PATCH v3 00/11] : More warnings as errors by default
<https://inbox.sourceware.org/gcc-patches/cover.1700473918.git.fwei...@redhat.com/>
Jeff as a global reviewer has delegated review to Marek.
The current series is based on an earlier suggestion to do as much as
possible in one transition. The full list of upgraded warnings is:
-Wimplicit-function-declaration
-Wimplicit-int
-Wint-conversion
-Wreturn-mismatch (new, previously part of -Wreturn-types)
-Wdeclaration-missing-parameter-type (new, previously unnamed)
-Wincompatible-pointer-types
Fedora has a set of about 15,000 source packages which are built with a
GCC compiler in the buildroot. Until recently, we only had experience
with dealing with -Wimplicit-function-declaration and -Wimplicit-int
issues. We have implemented fixes or workaround in about 860 packages
for those two warnings. Where possible, these fixes have been sent
upstream, but of course in many cases, upstream has been dormant for a
while or not around at all anymore.
We now have Fedora test builds with an instrumented GCC that covers all
the warnings listed above. The data is skewed somewhat because we
underwent an unscheduled libxml2 API transition at the same time, and
also had a glibc crypt declaration regression initially. I'm going with
the numbers I have today. They include cleanups for about 50 packages
for various issues (most prominent ones being bash and xterm).
autoconf
all only
implicit-function-declaration 53 21
implicit-int 2 0
int-conversion 99 33
return-mismatch 13 2
declaration-missing-parameter-type 0 0
incompatible-pointer-types 374 50
497 89
Numbers do not tally up because one package can have multiple issues.
The autoconf column counts packages where file-name based heuristics
suggest the critical errors are in autoconf-style feature probes, where
they are ignored and could silently alter the results. My focus will be
on fixing those packages.
These numbers include a certain amount of false positives, especially
for implicit-function-declaration and incompatible-pointer-types, but
the GCC instrumentation has improved somewhat and now uses unrelated
errors (e.g., about unknown types, or incorrect number of function
errors) to suppress logging of the critical errors.
Looking at the numbers, everything seems quite doable except
incompatible-pointer-types. (Keep in mind that these numbers are based
on over 15,000 packages.) Instead of the incompatible-pointer-types
error, Clang only went with a subset (not yet implemented by GCC) called
incompatible-function-pointer-types, but I'm not sure if it would result
in a substantial amount of work reduction. The status as a warning for
non-function pointers definitely hides real bugs (for example, an
out-of-bounds write in PyTables on 32-bit architectures).
I suggest we put in the incompatible-pointer-types upgrade for now
(pending review), and see how it goes in Fedora. I plan to backport
these changes to GCC 13 as used in our current development version, so
that we can gain some feedback from package maintainers before we import
GCC 14 (which is expected to happen well before the GCC upstream
release). If feedback is overly negative, I'm going to suggest that GCC
disables it again for the GCC 14 release, although that would run
counter to the request for one transition only.
Thoughts?
Excluded above are systemic issues related to Vala, which does not
produce valid C in many cases. I will probably have to look into
teaching Vala to emit diagnostic pragmata in the generated C sources
because they are not expected to be valid C (although again, this really
seems to be hiding application bugs in some cases).
Thanks,
Florian
