From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C171B17FE0 for ; Tue, 9 May 2023 17:10:16 +0000 (UTC) References: <877cth66qb.fsf@oldenburg.str.redhat.com> <97CCB305-9ECD-4B3C-B13E-4F2790FE0543@gmail.com> <87pm794f1m.fsf@oldenburg.str.redhat.com> User-agent: mu4e 1.10.3; emacs 29.0.90 From: Sam James To: Florian Weimer Cc: Richard Biener , gcc@gcc.gnu.org, c-std-porting@lists.linux.dev Subject: Re: More C type errors by default for GCC 14 Date: Tue, 09 May 2023 18:07:16 +0100 In-reply-to: <87pm794f1m.fsf@oldenburg.str.redhat.com> Message-ID: <87h6sljurv.fsf@gentoo.org> Precedence: bulk X-Mailing-List: c-std-porting@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Florian Weimer writes: > * Richard Biener: > >>> 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 default behavior with still being able to undo this using >> -Wno-error=3D or -Wno-? > > That's what Clang does (and the defaults chang along with -std=3D > settings). To me, -Werror by default for some warnings seems rather > hackish. But that's just my personal preference, I do not have a strong > objection to doing it that way. Not that we have to follow Clang, but deviating by adding -fpermissive (which is a GCC-only flag) for C may not be desirable, and following Clang would let people use the same method for silencing known-bad codebases for now. > > One downside with -Wno- is that some developers jump on this rather > quickly instead of fixing the real problem. So far, I've seen this in > both Chromium and the kernel, in fringe areas admittedly, but still. > The advantage is that there is a familiar workaround to get things > compiling quickly again, of course. > I've not seen very much of this so far, FWIW. Only for the more annoying C23 warnings which have well-documented problems (and unrelated to this, so I won't go on about it anymore). But -fpermissive does have a nice property in that it's immediately obvious you're doing something *terrible* if you use it. >> I think instead of hard-coding a set of changes would it be possible >> to alter the default setting of diagnostic options during GCC >> configuration? And maybe even note that when diagnosing? > > I'd be worried about our package maintainers if we do something like > that. We'd like them to report build failures upstream, and if it's > just one or two distributions doing that and not GCC upstream, well, I > guess we just got a preview of how some upstreams are going to react. > Package maintainers tend to be volunteer or junior engineering roles, I > think, so this doesn't seem fair to me. Yeah, this is one of those things where we need it happening in CI for people and at the point of development. (Such an option might be nice in general, but not for this if its default didn't include these warnings or if distributions were likely to override it to something weaker.) thanks, sam --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZFp+dF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZC5RgEA5ycsCpvGdGu1Wv2BBuj7tngxFLSeUpWXp/33 W6MlF1YBALGG0TDejRUoEjYBXLuAyZS7zQXhV11HDtuL+a/LN98B =LDN7 -----END PGP SIGNATURE----- --=-=-=--