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

[Sam James <sam@gentoo.org>]

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