From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 24F8017FE0 for ; Tue, 9 May 2023 16:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683651545; 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=1J/eRJ8vO3PNbVDYvjGHIwn9HvKTJhrxkY7FTTULTiY=; b=iYOVgkG1o5e3Y9qj6oV2tFSBvY5iLXRwHREGcs9SUAPD1L8Su6lUSrVuALDdEuf4cwMqu6 duY7CCQfWNi92ZlNdrluOwi3nBKCS9beNpl5z7KOIIWxOWFn1oNSPPg8zOB1E8OQaXhUGW kmveRs6loddmjeRmsW4D8Pt4FLeYtzA= 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-660-BOqWAc2BO1S9cE3XUeq1vg-1; Tue, 09 May 2023 12:59:04 -0400 X-MC-Unique: BOqWAc2BO1S9cE3XUeq1vg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 47FE93C23942; Tue, 9 May 2023 16:59:04 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6E1ED40C6E67; Tue, 9 May 2023 16:59:03 +0000 (UTC) From: Florian Weimer To: Richard Biener Cc: 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> Date: Tue, 09 May 2023 18:59:01 +0200 In-Reply-To: <97CCB305-9ECD-4B3C-B13E-4F2790FE0543@gmail.com> (Richard Biener's message of "Tue, 9 May 2023 17:16:19 +0200") Message-ID: <87pm794f1m.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Precedence: bulk X-Mailing-List: c-std-porting@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable * 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. 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 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. Thanks, Florian