Update on GCC 14 C type safety changes/warnings as errors

Update on GCC 14 C type safety changes/warnings as errors

[Florian Weimer]

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.fweimer@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

Re: Update on GCC 14 C type safety changes/warnings as errors

[Sam James]

Florian Weimer via Gcc <gcc@gcc.gnu.org> writes:

> [...]
> 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.

incompatible-pointer-types at least suffers from some expected errors
with e.g. strerror_r which you may want to just export the cache var for in a
glibc environment at least for testing.

Mine as well.

>
> 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?

This sounds fair and in line with my observations. I lean towards us
being able to pull it off but if needed, reverting that specific change
later on in 14 development isn't the end of the world.

Of course, you've added -fpermissive for a reason anyway, so we have
that too.

I hadn't considered exposing a patched GCC 13 to developers and might do
the same, not sure how much take up there'd be on our end without some
runtime toggle instead. Will have a think, but not really worried about
it anyway, as the tinderboxes have great covergae & will run whatever
version we want.

> [...]

Thank you again for doing this Florian.

sam

Re: Update on GCC 14 C type safety changes/warnings as errors

[Martin Jambor]

Hello,

On Thu, Nov 30 2023, Florian Weimer via Gcc wrote:
> 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.fweimer@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

[...]

>
> Thoughts?
>

First and foremost, thanks a lot for working on this and especially for
starting with the enormous task of dealing with the fallout.

Given you probably have the most experience with it, can you please also
suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that
would describe this change?  (I was thinking of proposing something
myself, but I don't really know just how much verbose such an entry
should be.)

Thanks!

Martin

Re: Update on GCC 14 C type safety changes/warnings as errors

[Florian Weimer]

* Martin Jambor:

> Given you probably have the most experience with it, can you please also
> suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that
> would describe this change?  (I was thinking of proposing something
> myself, but I don't really know just how much verbose such an entry
> should be.)

Thank you for the reminder.  I veered somewhat on the verbose side and
submitted:

  [PATCH] Notes on the warnings-as-errors change in GCC 14
  <https://inbox.sourceware.org/gcc-patches/87v876ssxg.fsf@oldenburg.str.redhat.com/>

Florian