From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id AB3B73852912 for ; Wed, 10 May 2023 12:43:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB3B73852912 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> <83wn1g8kga.fsf@gnu.org> User-agent: mu4e 1.10.3; emacs 29.0.90 From: Sam James To: Eli Zaretskii Cc: Eric Gallager , jwakely.gcc@gmail.com, joel@rtems.org, dje.gcc@gmail.com, jakub@redhat.com, arsen@aarsen.me, gcc@gcc.gnu.org Subject: Re: More C type errors by default for GCC 14 Date: Wed, 10 May 2023 13:42:16 +0100 In-reply-to: <83wn1g8kga.fsf@gnu.org> Message-ID: <87ttwkgxvi.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii via Gcc writes: >> From: Eric Gallager >> Date: Wed, 10 May 2023 06:40:54 -0400 >> Cc: joel@rtems.org, David Edelsohn , Eli Zaretskii ,=20 >> Jakub Jelinek , Arsen Arsenovi=C4=87 ,=20 >> "gcc@gcc.gnu.org" >>=20 >> Idea for a compromise: What if, instead of flipping the switch on all >> 3 of these at once, we staggered them so that each one becomes a >> default in a separate release? i.e., something like: >>=20 >> - GCC 14: -Werror=3Dimplicit-function-declaration gets added to the defa= ults >> - GCC 15: -Werror=3Dimplicit-int gets added to the defaults >> - GCC 16: -Werror=3Dint-conversion gets added to the defaults >>=20 >> That would give people more time to catch up on a particular warning, >> rather than overwhelming them with a whole bunch all at once. Just an >> idea. > > What do we tell those who cannot possibly "catch up", for whatever > valid reasons? E.g., consider a program written many years ago, which > is safety-critical, and where making any changes requires so many > validations and verifications that it is simply impractical, and will > never be done. Why would we want to break such programs? Upgrading the toolchain is a change which requires validation, surely. They can then test it at the same time as porting to modern C. Or simply set the required options (as we're discussing) to allow older, to-be-rejected constructs. (It's also not clear to me that they're entitled to a GCC which always works for them forever. People who like the behaviour of older GCCs and refuse to change anything about their environment (not necessarily their code) are able to stick with old versions if they wish.) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZFuRgl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZCFvwEAoofEFEf3XdbpOKll5ZOxsXqiPGi/ObTzfT11 9vZDwc4A/RJfXAstmShQwFK1GSNSVBO1FKlcgtVMm0/o6ltLVPIB =JHjL -----END PGP SIGNATURE----- --=-=-=--