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.
Specifically, I'm investigating the following changes:[reordered]
* -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.
I want to propose at least the first two for GCC 14.[reordered]
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.
* (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 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.
At 2023-04-18T16:07:45+0200, Florian Weimer wrote:
TL;DR: I want to propose a GCC 14 change which will impact
distributions, so I'd like to gather some feedback from Debian.
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.
Debian has little fear of sweeping transitions, but it does like them to
be precisely defined in scope, and easily measured in adoption. The
addition of a versioned contour flag to "DEB_BUILD_OPTIONS" or
similar[3] is straightforward to measure by scanning source packages.
TL;DR: I want to propose a GCC 14 change which will impact
distributions, so I'd like to gather some feedback from Debian.
I would appreciate some discussion on the Debian impact.
On Tue, 2023-04-18 at 16:07 +0200, Florian Weimer wrote:
TL;DR: I want to propose a GCC 14 change which will impact
distributions, so I'd like to gather some feedback from Debian.
Is this change being made the upstream defaults?
Or will it be a distro override like the hardening flags are?
I would appreciate some discussion on the Debian impact.
Since most of the Debian archive can be reproducibly built, it seems
like the way to gauge the impact of this change on Debian would be to
do two archive rebuilds, once without the flags and once with the
flags, then compare the two builds for each package using diffoscope.
The reproducible builds fuzzing tests get 96.2% reproducible,
this would only go up when not varying most of the fuzzed things.
https://tests.reproducible-builds.org/debian/reproducible.html
The existing documentation for Debian archive rebuilds is outdated and deleted, but Lucas Nusbaum and others have been doing them for a while.
https://wiki.debian.org/MassRebuilds https://wiki.debian.org/qa.debian.org/ArchiveTesting?action=recall&rev=23
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.
[[PGP Signed Part:Undecided]]
On Tue, Apr 18, 2023 at 16:07:45 +0200, Florian Weimer wrote:
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.
For Gentoo, I wrote (with some help from others) this QA check [1] which Portage uses to scan Autoconf, CMake, and Meson config logs for implicit function declarations. It's inspired by a similar bit of code from the Macports folks [2] and written with both Clang and GCC in mind.
It should be possible to adapt for use by others if you feed it the
right dirs and replace a few functions (`has` and `eqa*` OTTOMH) since nothing about the core logic is Portage-specific.
Although not so much for silent failures, but maybe still useful for
someone, there's also this QA check [3] which is used to detect other warnings at build-time.
- Oskari
Perhaps the thing to do here is have, <gulp>, yet another command-line
option for GCC. The Ada language did something similar a couple of
decades ago to tighten up the language for hard real-time demands, with
what it called the "Ravenscar profile".[1] That proved successful (as successful as anything was in poor neglected Ada).
Whatever its name, some advantages to this approach are that
distributors could opt-in to such a thing, make it a clear matter of
policy, and more easily track adoption and progress. You could also
version the contour much like the C standard itself.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 360 |
Nodes: | 16 (2 / 14) |
Uptime: | 129:07:50 |
Calls: | 7,686 |
Files: | 12,828 |
Messages: | 5,711,155 |