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.133.124]) by sourceware.org (Postfix) with ESMTPS id 55AE83858D37 for ; Tue, 9 May 2023 16:44:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 55AE83858D37 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=1683650697; 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=oam21wP0xmBIOvtkwPCIEFZxDxUjPlrEu+rwmDLE13A=; b=L56sENE6/6BXtAkxxHaBbU+BwVsMtN9/xzHqsMkpRyeI9TR3J0dA6qhz9+4OHdy/eTC5SS DAPDK9JSbFeq7/jgZiyjCUMXhk+UfO0rmUCFCRuzKnymrdMBmRG39/nn2B0Ic0PQRr4C7i n5ylgiiQsiyhRAsj22qqau01y+DypCs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-52-c-vOhZzEO3-_OzmO6duIxw-1; Tue, 09 May 2023 12:44:51 -0400 X-MC-Unique: c-vOhZzEO3-_OzmO6duIxw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id ED756101A55C; Tue, 9 May 2023 16:44:50 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD04F492C13; Tue, 9 May 2023 16:44:49 +0000 (UTC) From: Florian Weimer To: Richard Biener Cc: David Edelsohn , Jakub Jelinek , gcc@gcc.gnu.org, c-std-porting@lists.linux.dev Subject: Re: More C type errors by default for GCC 14 References: Date: Tue, 09 May 2023 18:44:48 +0200 In-Reply-To: (Richard Biener's message of "Tue, 9 May 2023 18:18:02 +0200") Message-ID: <87y1lx4fpb.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.10 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.3 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,RCVD_IN_MSPIKE_H2,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: * Richard Biener: > > Am 09.05.2023 um 18:13 schrieb David Edelsohn : > > > > =EF=BB=BFOn Tue, May 9, 2023 at 12:07=E2=80=AFPM Jakub Jelinek via Gcc = wrote: > > > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrote: > > >=20 > > >=20 > > > > 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 err= ors > > > > for GCC 14. > > >=20 > > > 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-? > > > > Can't people just compile C89/K&R code with -std=3Dc89/-std=3Dgnu89 and= not get > > these errors that way? > > > > As Florian mentioned: > > > > "Presently, we > > cannot use -std=3Dgnu89 etc. to opt out because there are packages whic= h > > require both C89-only language features and C99-style inlining, which i= s > > currently not a combination supported by GCC (but maybe that could be > > changed). " > > But surely it would reduce the number of packages to fix? So I > support both having only C99 and up reject no longer valid code _and_ > having -fpermissive be forgiving (demoting errors to warnings). It makes sense to disable the new erros in C89 mode. It's what I did in the instrumented compiler. It also gives you yet another way to disable the errors, using CC=3Dc89, which works for some packages that do not honor CFLAGS and do not support whitespace in CC. The part David quoted above is about this: $ gcc -fno-gnu89-inline -std=3Dgnu89 t.c cc1: error: =E2=80=98-fno-gnu89-inline=E2=80=99 is only supported in GNU99 = or C99 mode And some packages need -fno-gnu89-inline, but also rely on implicit ints and implicit function declarations heavily. With a purely C89-based opt-out and the -fno-gnu89-inline limitation, we wouldn't have a way to compile these self-contradictory programs. Hence the idea of -fpermissive, in addition to the -std=3Dgnu89 escape hatch. But perhaps the -fno-gnu89-inline limitation is easy to eliminate. The remaining reason for -fpermissive would be a flag that is accepted by both gcc and g++, in case a package build system passes CFLAGS to g++ as well, which sometimes happens. And -fno-gnu89-inline is currently not accepted by g++. But in the Fedora package set, this (some C++ and a C89 requirement) must be exceedingly rare because it's a subset of the already tiny set of -fno-gnu89-inline -std=3Dgnu89 packages. Thanks, Florian