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 0DEB83858D37 for ; Tue, 9 May 2023 17:08:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0DEB83858D37 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=1683652115; 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=rY99HJlkcH4+Hymzesn1qC4Hr9ijeQ6TP4OKv7Cmjhw=; b=Cypjws3wnC3eMvJPAMp3exC1XoGjqUZ7+4OESw5hYzguhY+p3ny4Z9hEwmZe6BqBSXOHFO AEnAgpq062/yuMkmCAv+mURzQ2WDBDullak5pmFjfD5aVIBFKIDP1HhkR9gZjNI51PUjG7 B0u1WBWnYI34akwRWGTzKtzX1pD9g2s= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-196-RTVRPo9HNkiwdWhxOg3h2g-1; Tue, 09 May 2023 13:08:34 -0400 X-MC-Unique: RTVRPo9HNkiwdWhxOg3h2g-1 Received: by mail-il1-f198.google.com with SMTP id e9e14a558f8ab-331139b46cfso40339665ab.1 for ; Tue, 09 May 2023 10:08:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683652113; x=1686244113; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rY99HJlkcH4+Hymzesn1qC4Hr9ijeQ6TP4OKv7Cmjhw=; b=GOJC57WO5Kapf2sGgE1A7oaPvIODWUlwjGFrm8fixoHPDUUjjSwIJwSobz/9+DR/xn OxRLO8E87aN1O5+NhRvvnn+XQLo5ktPNtU2TayKL92hBOAQLpzGiYF2SiRlPnelRRs9J +hWa23uIVtUQB3yQdIc3VSliwLPaVNOKkKeH/5p5ffOyBpCluenY3R/YQk0n+hjlvF+N DrIRw470QI6byrPDMlgdNhCt73lqbtelW6LCyAeHH1+8WD+D0FGlTI4/snUNtH5aViRq 1Tonv08VBs5mFwPzRkdeRLsI1zwIiEzQN1emDXW7R2pUf/NTKYkbYe8ppW0Dnp46GNgx zPmw== X-Gm-Message-State: AC+VfDzNKhGiM8xLKShlnmCwfQ/x3sk/gxfc9wPc15vXSu5RjN4CDJ3J bIb3+i96n9qtwUmXOIwoXdzHceVINY6Tg5hw8pQU6KUFvL6jocoBFNCmL6x3HVhYnkNocWTXZnc AGP2PwMjy5Z7q9efnAJ1FBxM= X-Received: by 2002:a05:6e02:804:b0:334:7263:6283 with SMTP id u4-20020a056e02080400b0033472636283mr8094983ilm.14.1683652113666; Tue, 09 May 2023 10:08:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5fAxiAzDKUt4aHj9F8rofKr1m0sJn4IkHYgyZujdsZ7jM1cpJWuXh9lGN1f/uLY8R7CKJ3QaPgDSphCU6FRmI= X-Received: by 2002:a05:6e02:804:b0:334:7263:6283 with SMTP id u4-20020a056e02080400b0033472636283mr8094959ilm.14.1683652113360; Tue, 09 May 2023 10:08:33 -0700 (PDT) MIME-Version: 1.0 References: <87y1lx4fpb.fsf@oldenburg.str.redhat.com> In-Reply-To: <87y1lx4fpb.fsf@oldenburg.str.redhat.com> From: Jason Merrill Date: Tue, 9 May 2023 13:08:22 -0400 Message-ID: Subject: Re: More C type errors by default for GCC 14 To: Florian Weimer Cc: Richard Biener , David Edelsohn , Jakub Jelinek , gcc@gcc.gnu.org, c-std-porting@lists.linux.dev 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=-6.2 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: On Tue, May 9, 2023 at 12:45=E2=80=AFPM Florian Weimer via Gcc wrote: > > * 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 Gc= c wrote: > > > > > > On Tue, May 09, 2023 at 05:16:19PM +0200, Richard Biener via Gcc wrot= e: > > > > > > > > > > > > > Am 09.05.2023 um 14:16 schrieb Florian Weimer via Gcc : > > > > > > > > > > =EF=BB=BFTL;DR: This message is about turning implicit-int, > > > > > implicit-function-declaration, and possibly int-conversion into e= rrors > > > > > 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-? > > > > > > Can't people just compile C89/K&R code with -std=3Dc89/-std=3Dgnu89 a= nd not get > > > these errors that way? > > > > > > As Florian mentioned: > > > > > > "Presently, we > > > cannot use -std=3Dgnu89 etc. to opt out because there are packages wh= ich > > > require both C89-only language features and C99-style inlining, which= is > > > 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 GNU9= 9 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. Another reason for -fpermissive is ease of use. So if someone just wants to get an older package to build, they can add -fpermissive without having to figure out more detailed flags. Alternatively, if we go the default -Werror=3Dvarious route, adding -Wno-error without any =3Dfoo to override everything might also be fairly convenient. In any case, I think we want an easy answer for the second group. Jason