From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 12B8A3858C53 for ; Tue, 9 May 2023 15:03:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12B8A3858C53 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-x536.google.com with SMTP id 4fb4d7f45d1cf-50bc0117683so10899713a12.1 for ; Tue, 09 May 2023 08:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683644614; x=1686236614; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/R/d5QtKfvqQJ6JuexUz6nAVeNxDnOf1b5/JkDoH8js=; b=UFOba8YXYNdW5C8bytTq3yErQopRU+FEVqWOqvilkN+hDfMdEXS/tCxT69yQQsKqrm atIMZy3LjtiuBedsQYB1DfNKwf43zAoooODScRojf9HBLr2wRqePzi+anc0xWnmvjJIZ 60Re74AKEvham5OfRMF8x/ge+Tab0idnrBwhVvDGrifXWKEmQlIbIYglz3+3TDe8lJ+l ni38W4k7fQxdOthYLEpJkd/lS/oDf5otgpVrJ0XL7M/iQlPZnXrml1cXeANXYXzns6Tf AXeHqXyMhkN/iELg39tiAMvdQ+WFaiiJY/lQS0RPsTCRVwXY66zgTvWTXywBwq1ZS17h oj9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683644614; x=1686236614; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/R/d5QtKfvqQJ6JuexUz6nAVeNxDnOf1b5/JkDoH8js=; b=X0iFssDfiOIwoqp77I7DKoDnIs5NtszlfrKxL9KxewGEwtnhJn73D4BV/O/7XmoNIM 59/mZPGCESGlyNpittiXFiKLroXCuh4eaJkHOk4IGB/7QM+UPfwXbYV9trHTR/kG8bss R8BQyagBP6vCnuMQMJaxSipa/VRkcjJtlmYuwF0c/L9n3G3MeP+mbUtNtlit51Cxy9yS xNDE9VqqVM/dlusEvlXYVnI0XchJWcjCAZNaLqFAcvBVgjV2GWl+jwwsTBHtxCVRiNy9 SsN0ngt18jPUjw3w3RaH2B88F6ZWh/A7ZPN0qxLPA36PzV4UtttIZIsUUcgu7+DITIsi 2GOg== X-Gm-Message-State: AC+VfDyeoGltGn/+R/WNergwxITcMI2Vdlhn4BuLKZXCq8xNF0AIv5bG PpeZLGLtJ5021S0IW6FnaO0Dsp3RtE5QjA6ZR0g= X-Google-Smtp-Source: ACHHUZ7aECz3n1daadPWISJZ5hZ3xFiXrD8wxfgW6pujchPvUJ+jHO+kmxl/KjRiATuZVpAS/3k0oxAMcu0cLiqxMQk= X-Received: by 2002:aa7:cd53:0:b0:50b:c49b:62d4 with SMTP id v19-20020aa7cd53000000b0050bc49b62d4mr10940819edw.28.1683644614393; Tue, 09 May 2023 08:03:34 -0700 (PDT) MIME-Version: 1.0 References: <877cth66qb.fsf@oldenburg.str.redhat.com> In-Reply-To: <877cth66qb.fsf@oldenburg.str.redhat.com> From: David Edelsohn Date: Tue, 9 May 2023 11:03:22 -0400 Message-ID: Subject: Re: More C type errors by default for GCC 14 To: Florian Weimer Cc: gcc@gcc.gnu.org, c-std-porting@lists.linux.dev Content-Type: multipart/alternative; boundary="0000000000002b421a05fb440f23" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,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: --0000000000002b421a05fb440f23 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 9, 2023 at 8:16=E2=80=AFAM Florian Weimer via Gcc wrote: > 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. > Hi, Florian Thanks for working on this and proposing this. Yes, GCC has two, distinct user groups / use cases, but GCC also has a very unique and crucial role, as the foundation for a large portion of the GNU/Linux and FOSS software ecosystem. This proposal is missing a motivation for this change, especially making new errors the default. GCC needs to be proactive, not reactive, without annoying and frustrating its user base. Clang has been making some aggressive changes in warnings, but its constituency expects that. Developers who want that experience already will use Clang, so why annoy developers who prefer the GCC experience and behavior? The new warnings and errors help some developers and improve software security, but also drive some developers away, or at least cause them to reass their choice of toolchain. Maybe we need additional front-end aliases "gcclang" and "gcclang++" for GCC to provide an experience more like Clang for those who desire that. GCC isn't Clang and I fear that GCC is going down a path that annoys and frustrates both user groups -- it's not sufficiently aggressive for those who prefer Clang and it's too aggressive for those who wish backward compatibility. Thoughts? Thanks, David > > 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 f= or > us=E2=80=9D). > > < > https://discourse.nixos.org/t/rfc-more-c-errors-by-default-in-gcc-14/27390 > > > > < > https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/threa= d/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=3D=E2=80=A6 by default, but that seems a bit hackish to me. Pres= ently, 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 > > --0000000000002b421a05fb440f23--