c-std-porting.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: gcc@gcc.gnu.org
Cc: c-std-porting@lists.linux.dev
Subject: More C type errors by default for GCC 14
Date: Tue, 09 May 2023 14:15:40 +0200	[thread overview]
Message-ID: <877cth66qb.fsf@oldenburg.str.redhat.com> (raw)

TL;DR: This message is about turning implicit-int,
implicit-function-declaration, and possibly int-conversion into errors
for GCC 14.

A few of you might remember that I've been looking into turning some
type errors from warnings into errors by default.  Mainly I've been
looking at implicit function declarations because in too many cases, the
synthesized declaration does not match the prototype used at function
definition and can cause subtle ABI issues.

To recap, the main challenge is that GCC has to serve disparate groups
of users: some use GCC for writing programs themselves, but others just
need GCC to build sources that they have obtained from somewhere.  The
first group benefits from more type errors because they catch errors
earlier during development (experience shows that compiler warnings are
easy to miss in a long build log).  The second group might find these
errors challenging because the sources they have no longer build.

To see how large the impact is on that second group, we've mostly
removed implicit function declarations and implicit ints from Fedora:

  <https://fedoraproject.org/wiki/Changes/PortingToModernC>
  <https://fedoraproject.org/wiki/Toolchain/PortingToModernC>

Roughly 870 packages out of ~14,500 that have GCC present during the
build needed fixing (or flagging that they can't be built with the
additional errors), so 6%.  Most of the changes are mechanical in
nature, like adding additional headers to configure checks.  For about
~150 packages, automated patching could be used to rewrite problematic
built-in checks generated by long-obsolete autoconf versions.

Some of these changes prevent the compiler behavior for altering the
build results silently because the new errors changed the outcome of
autoconf checks.  (We had one of those in libstdc++, changing the ABI on
GNU/Linux because futex support oculd no longer be detected.)
Unfortunately, I did not record numbers about them, but think those were
quite rare; most autoconf problems were also accompanied with other
problems, or the incorrect results from autoconf led to build failures
later.  So it seems to me that the risk that the second group mentioned
above would silently get unexpected build results is fairly low.

Where possible, we tried to upstream patches, to simplify sharing across
distributions and to help those who compile upstream sources directly.
We also benefited from other distributions upstreaming changes along
similar lines (notably Gentoo for their Clang 16 project, but also from
Homebrew to a lesser extent).

An area we started exploring only recently for Fedora is implicit
conversions between integers and pointers (covered by -Wint-conversion).
These add another ~170 packages, but some of those are false positives
(due to our instrumented compiler approach) that do not change the build
outcome at all.  I'm still negotiating whether we have the capacity to
develop fixes for these packages proactively.

I brought up the matter with distributions, and the feedback was neutral
(not overly negative, as in “this would be the end of the world for
us”).

  <https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390>
  <https://lists.debian.org/debian-gcc/2023/04/msg00015.html>
  <https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/5OL76NH5AX75WOTZ43O3ZF2JOS3ABBXL/#QZLCA5YPN5CWSS7BCC6TNBC6N7RFTW7J>

(I tried to contact Arch, but my message didn't make it past the
moderators, it seems.)

All in all, the whole situation is not great, but it still seems
manageable to me.

Anyway, thanks for reading this far.

I would like to suggest to turn implicit-int,
implicit-function-declaration, and possibly int-conversion from warnings
into errors for GCC 14.  This would give upstream projects roughly
another year to make new releases with compatibility fixes that have
been contributed so far.  I do not think waiting longer, until GCC 15,
would make a meaningful difference because any upstream project that
does not release within the next 12 months is not likely to release in
the next 24 months, either.

Regarding mechanics of the necessary opt out facility, Clang used
-Werror=… by default, but that seems a bit hackish to me.  Presently, we
cannot use -std=gnu89 etc. to opt out because there are packages which
require both C89-only language features and C99-style inlining, which is
currently not a combination supported by GCC (but maybe that could be
changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
separate, and a flag approach that works for C and C++ without
introducing any new warnings would be most convenient.  So maybe we
could use -fpermissive for C as well.

One fairly big GCC-internal task is to clear up the C test suite so that
it passes with the new compiler defaults.  I already have an offer of
help for that, so I think we can complete this work in a reasonable time
frame.

I have no data how big the compatibility impact of turning
incompatible-pointer-types into errors will be.  For now, int-conversion
has higher priority.  However, it looks like another change that could
benefit developers (the first group).

I do not plan to work specifically on C2X compatibility fixes for now
(to support bool-as-keyword, for example), but I could imagine a similar
project a few years from now, fewer than 25 hopefully, that would enable
GCC to make the switch to C2X by default.

Thanks,
Florian


             reply	other threads:[~2023-05-09 12:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 12:15 Florian Weimer [this message]
2023-05-09 15:16 ` More C type errors by default for GCC 14 Richard Biener
2023-05-09 16:05   ` Jakub Jelinek
2023-05-09 16:11     ` Sam James
2023-05-09 16:59   ` Florian Weimer
2023-05-09 17:07     ` Sam James
2023-05-09 17:35       ` Florian Weimer
     [not found] ` <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
2023-05-09 15:07   ` Sam James
2023-05-09 15:14   ` Jonathan Wakely
     [not found]     ` <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
     [not found]       ` <87r0rp5uf8.fsf@aarsen.me>
     [not found]         ` <83ttwla1ep.fsf@gnu.org>
     [not found]           ` <CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
     [not found]             ` <83lehx9vix.fsf@gnu.org>
     [not found]               ` <ZFqZ25xKm4w4IkqF@tucnak>
     [not found]                 ` <83fs859unu.fsf@gnu.org>
     [not found]                   ` <CAGWvny=xi++Ghyo2Ez5MJdYy5h3yH16gVpviKC99Ufu_bUmdYQ@mail.gmail.com>
     [not found]                     ` <CAH6eHdRAVwBcCmBgiuPyQNWGx3x33diAgQU8UG3s_NrJxK3ucQ@mail.gmail.com>
     [not found]                       ` <CAGWvnyk_MkQOrNNh1C=ubPj8qzg5x-p8CBfgWNqqtDVJ1mbhMg@mail.gmail.com>
     [not found]                         ` <CAF9ehCWsq-N9+U1+mTQahKT7cXEqLTptLb=b3Yq58gsWFEnxgA@mail.gmail.com>
     [not found]                           ` <CAH6eHdS_sQ37VTpJHL7cqtgSdCSL3i4=tqMoY65wep9G56cf5g@mail.gmail.com>
     [not found]                             ` <CAMfHzOsR=gY6QTss2R029Q-uMOTpC-RDV09bEF2FO7x5jpy5gg@mail.gmail.com>
2023-05-10 10:45                               ` Sam James
2023-05-10 10:56                                 ` Neal Gompa
2023-05-10 12:06                                   ` Eli Zaretskii
2023-05-10 12:10                                     ` Neal Gompa
2023-05-10 12:41                                       ` Eli Zaretskii
2023-05-09 18:22   ` Florian Weimer
2023-05-11 21:32     ` Segher Boessenkool
2023-05-12  9:33 ` Martin Jambor
2023-05-12 12:30   ` Jakub Jelinek
2023-05-15 12:46     ` Michael Matz
2023-05-15 13:14     ` Richard Earnshaw (lists)
     [not found] <CAGWvnynMpa83AduLhRhf1PxkVujngDmmwE7Z4vk1z6+UqqAuKA@mail.gmail.com>
     [not found] ` <BBE9950C-28AA-4A1C-A4C5-7F486538004E@gmail.com>
2023-05-09 16:44   ` Florian Weimer
2023-05-09 16:58     ` Ian Lance Taylor
2023-05-09 17:08     ` Jason Merrill
2023-05-09 17:16       ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877cth66qb.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=c-std-porting@lists.linux.dev \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).