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.129.124]) by sourceware.org (Postfix) with ESMTPS id 8B8D73857343 for ; Tue, 9 May 2023 17:35:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8B8D73857343 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=1683653757; 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: in-reply-to:in-reply-to:references:references; bh=z8PK9NwsiTA3Z5ZqiRNIsw1+D+O530G+gt0dNBWMlhQ=; b=hd6bZkVAfJwfyjPPoKbT8RYMykUrVbDx+HjHb0rld7SXEuUkIpvqZiIp32odQ8SyW0l8wC /aSp70/P7AUSAodXDrhKKhhHoxwtTfZCvUqzIg7vw2ARPzp8pTR4vlgtHuiiMvhyCDE6yt 999ml5wKhfhZgSYZqrdRccALdgrJLDY= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-595-B5BdbKsgMZK8kCoYUL8BrQ-1; Tue, 09 May 2023 13:35:53 -0400 X-MC-Unique: B5BdbKsgMZK8kCoYUL8BrQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 151113C0F1A5; Tue, 9 May 2023 17:35:53 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 375701121315; Tue, 9 May 2023 17:35:52 +0000 (UTC) From: Florian Weimer To: Sam James Cc: Richard Biener , gcc@gcc.gnu.org, c-std-porting@lists.linux.dev Subject: Re: More C type errors by default for GCC 14 References: <877cth66qb.fsf@oldenburg.str.redhat.com> <97CCB305-9ECD-4B3C-B13E-4F2790FE0543@gmail.com> <87pm794f1m.fsf@oldenburg.str.redhat.com> <87h6sljurv.fsf@gentoo.org> Date: Tue, 09 May 2023 19:35:50 +0200 In-Reply-To: <87h6sljurv.fsf@gentoo.org> (Sam James's message of "Tue, 09 May 2023 18:07:16 +0100") Message-ID: <87fs854dc9.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.3 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.6 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,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: * Sam James: > 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. I think Clang already accepts -fpermissive, so it's not *too* bad? (Presumably it just ignores it.) >> 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). I think this could be a side effect of our different testing strategies. The kernel -Wno-implicit-function-declaration change looks like it was specifically added to build with Clang 15/16. > But -fpermissive does have a nice property in that it's immediately > obvious you're doing something *terrible* if you use it. Right. > In addition to this, this made me realise something similar to what > Florian was saying wrt whitespace. Passing -Wno-error=3D... doesn't > always work with some poorly-written build scripts because they split > on '=3D' (this happens with some CMake when poorly written). Hmm, maybe I've seen this as well but attributed it to whitespace. The -std=3Dgnu89 approach would run into problems with this, too. Thanks, Florian