TL;DR: I want to propose a GCC 14 change which will impact
distributions, so I'd like to gather some feedback from Debian.
Clang has disabled support for a few historic C features by default over
the last few releases. This mirrors a process that Apple has begun in
Xcode even earlier (perhaps motivated in part by their AArch64 Darwin
ABI, which is pretty much incompatible with some of the C89-only
features).
These changes bring real benefits to C programmers because errors are
much harder to miss during the build than warnings. In many cases, the compiler is not able to generate correct code when such issues are
present, and programmers who look at the generated machine code suspect
a compiler bug. And all this happens because they missed a warning. So
we want this change for GCC, too.
On the other hand, many distributions use GCC as the system compiler,
and there the focus is not so much on developing software, but building
the sources as they exist today. It's somewhat different the usual GCC
C++ updates (both language changes and libstdc++ header changes) because
it impacts pre-build feature probing (mostly autoconf). If that happens
and the probe goes wrong due to a new compiler error, it's possible that
a build still succeeds, passes its test suite, but lacks the intended
feature or ABI because parts got automatically disabled due to the
failing configure check. With C++ transitions, that seems more rare
(C++ programs—if they use autoconf—often run the checks with the C compiler).
Specifically, I'm investigating the following changes:
* -Werror=implicit-function-declaration: Functions can no longer be
called without be declaring first. Fixing this may need additional
prototypes in package header files, or inclusion of additional header
files (both package-specific and system headers).
* -Werror=implict-int: int types can no longer be omitted in old-style
function definitions, function return types, or variable declarations
or definitions. Fixing that involves adding the int type (or the
correct type if it is not actually int). If there is already a
matching declaration in scope that has a different type, that needs
to be resolved somehow, too.
* (tentative) -Werror=int-conversion: Conversion between pointer and
integer types without an explicit cast is now a compiler error.
Usually fixed by one of the two things above. I do not have data yet
how many other cases remain after the initial issues are fixed, but
should have that in the coming weeks. (Quite frankly, I'm amazed that
we created 64-bit ports without making this an error.)
* (very tentative) -Werror=incompatible-pointer-types: GCC will no
longer automatically convert between pointer values of unrelated
pointer types (except when one of them is void * or its qualified
versions). The fallout from this could be quite large, I do not have
data yet. Clang does this for function pointer types only (probably
based on their ABI issues), but I'm not sure if it's a reasonable
distinction for our ABIs (the ppc64le cases I've seen had explicit
casts and no warnings).
* For -Wdiscarded-qualifies (e.g., using const pointers as non-const),
and -Wpointe-rsign (using char * as unsigned char *) I do not have any
plans.
I want to propose at least the first two for GCC 14.
The exact mechanism how the default is changed may not be -Werror=,
perhaps something along the lines of -fpermissive for C++. The C89
modes (-std=gnu89 etc.) will likely still enable all these features
(even if they are not part of C89). As an opt-out mechanism, -std=gnu89
is insufficient because there are packages out there which use features
which are C99-and-later-only in GCC (predominantly C99-style inlining, I believe) together with implicit-int/implicit-function-declaration.
For Fedora, we are using an instrumented compiler to find packages that
need fixing. More details on the process are here (but please ask if
you are interested in specifics):
<
https://fedoraproject.org/wiki/Changes/PortingToModernC>
<
https://fedoraproject.org/wiki/Toolchain/PortingToModernC>
The numbers so far don't look great, but are manageable. Fedora has
23,101 source package last time a looked. We have fixed 796 of them,
and 85 are still pending investigation (with 5-10 false positives
expected remaining). This puts the per-package failure rate at 3.8%. I
don't have data on silent failures; most issues do not seem to be
silent, and fully-silent packages are rare. The silent output-changing
issues definitely exist, they are usually accompanied by something else.
Those 3.8% also include some packages which we fixed by removing C89 constructs, but where the relevant autoconf tests failed for other
reasons.
Fedora would be hit pretty hard if we made the GCC switch without this preparation because we do a mass rebuild of the entire distribution
right after importing a new GCC upstream release. I have considered
automating some of the autoconf updates, but usually it's some generic
autoconf issue (long since fixed in autoconf) plus a package-specific
issue, so that doesn't seem to be particularly helpful.
The changes we have made in Fedora are captured here:
<
https://gitlab.com/fweimer-rh/fedora-modernc/-/tree/main/pkg>
In general, if there is an upstream reference for change (bug tracker,
mailing list), we have not filed downstream bugs. Neither if it's
something that is the result of an old autoconf bug. I don't know how
useful this data is going to be for other distributions.
Gentoo has been fixing various packages for building with Clang, which
covers a superset of the issues that need to be addressed:
[TRACKER] Support LLVM/Clang as alternative system compiler
<
https://bugs.gentoo.org/showdependencytree.cgi?id=408963&hide_resolved=0>
IIRC, Gentoo has its own mechanism to detect silent build breakage, but
I think it's mostly focused on autoconf, so it's less comprehensive, and
also fixes the stuff that is actually relevant to the distribution.
Like the Fedora effort, they try to upstream patches (if an upstream is
still around). Xcode/Homebrew/Macports users have upstreamed some
patches as well, but perhaps less consistently so. Most upstreams are receptive to the changes. If they reject them, it's mostly becaue of
CLA processes. But for Fedora, there's a large overlap between impacted packages and packages without an active upstream maintainer, which is
perhaps not unexpected.
I would appreciate some discussion on the Debian impact. As Debian
generally doesn't do mass rebuilds and we have upstreamed the fixes,
maybe the impact is somewhat reduced? Given that you'll get the fixes
as part of the rebases. Of course, other mass-changes might trigger
rebuilds at a larger scale. I guess it also depends on when you want to
update to GCC 14. The later, the more likely other packages have
already imported the upstream fixes. The alternative would be to apply
the fixes in a proactive manner, like we are trying to in Fedora.
Thanks,
Florian
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)