From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id EDEA53858C53 for ; Tue, 9 May 2023 12:15:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDEA53858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683634544; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Z9imo97KlnGOK2vLuwak70+mEmddNo9fGabx43AD/fg=; b=IEgVyLSpLORLzkcKiDJmoe10R9rsz1ra8z/BZQwTIuKKU1UdxWJv7zoASsd2qNVmu2aAEo OJjwa823p+9EmhexIUSf03THOa+z2/l9Qy4YQGOHMl6sruIMDoGnbs25wXUS5RjNYeoRN6 N0xfpXakist6VCh1DnzH9emIAfHvjAg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-32-rJ_xm_zxOcqvPpfjqRu6tw-1; Tue, 09 May 2023 08:15:43 -0400 X-MC-Unique: rJ_xm_zxOcqvPpfjqRu6tw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 5006C100F651; Tue, 9 May 2023 12:15:43 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 904781401C51; Tue, 9 May 2023 12:15:42 +0000 (UTC) From: Florian Weimer 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 Message-ID: <877cth66qb.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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: 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 =E2=80=9Cthis would be the end of the world for us=E2=80=9D). (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=3D=E2=80=A6 by default, but that seems a bit hackish to me. Presen= tly, we cannot use -std=3Dgnu89 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