From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 3272C3858410 for ; Tue, 9 May 2023 15:16:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3272C3858410 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-50bc4b88998so10896216a12.3 for ; Tue, 09 May 2023 08:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683645391; x=1686237391; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=Z5SaCW3iuFIX7/2JF84rM+Y+V4tM1rv3Elpwl04fG+k=; b=ShzpxJ9mOqoNKfabcauZP0/ELgVSaI2vuX6ItTyExIFCWyqvvc9D2oouzqn9stsprw XE9C00t6C21BLyLegVOMkwcEoL+1j2J5WDN9Z8R4stdml4QIY99XgwccNt8/Y07RjYx3 hEvY4c6m01mHdw+9xmervtIUVI+qYh2xmONZKOlfwldRUK/0aoaJJp3f6ELEm2aYq60x ZMib7D97oaiceLZfDu8DiUjM6gCgAPA+JlGpVzn1Z3JvVLY3auXB8DWXm/G1IqgpawgK ZxRIdlfQyckbrcjd+rjY28ZgltXWeoKIZvEuQ4mZujkwKLgzvZG/6uC5oKnyBWKSdK3i 0vuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683645391; x=1686237391; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Z5SaCW3iuFIX7/2JF84rM+Y+V4tM1rv3Elpwl04fG+k=; b=aMomssVrrQhv/DFQSUq7YTwvhSyRQmJiIlQOdthe+ogSyuiOrkTCnXyPud1XJYC02L wI0heGmnZAZf+MGzejraWIXPigfbTato7+f6QxkPBAoet/9LmxVEHUNOqLphHdtPwSam n5Gq6RXMI67JxZj23pZWBEVGFLpbiXOr5VAOytC5W5ys+Mx69RtV4EK4mjCVVcrZDX7j 4IEtdHyFt5s/O5ZKwwOG5xxQi9e7p4ixkB551Os7ZUBIl1fGJ9QsM9b1z9K4JXYDJ90G TFYKoRm+NgZRZ6JJpQa3k669GFcQdI5UHEdr+AX80jdstF4WGJIsP4UTjwkmVLoSB/N4 li9Q== X-Gm-Message-State: AC+VfDyjj7YHUlHEAbofHaj6I2cw0GU/I6wtdmd0mtBn7Y10zj3yIzNX K6rwoz+eMlJ50F/yRADnvmEsN67imgg= X-Google-Smtp-Source: ACHHUZ5lFo/aRo52McxmuSkFu4HNuFmGcIi73JTdoZcEsxkGjBJhtt0vDRaBeUm0vEF9DHjtrn1HRQ== X-Received: by 2002:aa7:da55:0:b0:50b:c780:2581 with SMTP id w21-20020aa7da55000000b0050bc7802581mr11581655eds.5.1683645390629; Tue, 09 May 2023 08:16:30 -0700 (PDT) Received: from smtpclient.apple (dynamic-095-118-063-238.95.118.pool.telefonica.de. [95.118.63.238]) by smtp.gmail.com with ESMTPSA id l23-20020aa7c3d7000000b004f9e6495f94sm863761edr.50.2023.05.09.08.16.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 May 2023 08:16:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: More C type errors by default for GCC 14 Date: Tue, 9 May 2023 17:16:19 +0200 Message-Id: <97CCB305-9ECD-4B3C-B13E-4F2790FE0543@gmail.com> References: <877cth66qb.fsf@oldenburg.str.redhat.com> Cc: gcc@gcc.gnu.org, c-std-porting@lists.linux.dev In-Reply-To: <877cth66qb.fsf@oldenburg.str.redhat.com> To: Florian Weimer X-Mailer: iPhone Mail (20E252) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc : >=20 > =EF=BB=BFTL;DR: This message is about turning implicit-int, > implicit-function-declaration, and possibly int-conversion into errors > for GCC 14. I suppose the goal is to not need to rely on altering CFLAGS but change the d= efault behavior with still being able to undo this using -Wno-error=3D or -W= no-? I think instead of hard-coding a set of changes would it be possible to alte= r the default setting of diagnostic options during GCC configuration? And m= aybe even note that when diagnosing? Thanks, Richard=20 > 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. >=20 > 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. >=20 > To see how large the impact is on that second group, we've mostly > removed implicit function declarations and implicit ints from Fedora: >=20 > > >=20 > 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. >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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 fo= r > us=E2=80=9D). >=20 > > > >=20 > (I tried to contact Arch, but my message didn't make it past the > moderators, it seems.) >=20 > All in all, the whole situation is not great, but it still seems > manageable to me. >=20 > Anyway, thanks for reading this far. >=20 > 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. >=20 > 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. Prese= ntly, 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. >=20 > 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. >=20 > 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). >=20 > 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. >=20 > Thanks, > Florian >=20