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 038EC39CB4E0 for ; Fri, 21 Oct 2022 22:13:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 038EC39CB4E0 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=1666390394; 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=Z5O3HF2pVbhXxNqNfm4NBAFrdyfw+i9DUtEpSf/OiK0=; b=JJgRfW45jo8UV/vZ2PV5H/NnOKygE2yOCfKOYlp1zdAcvXU6eQbpo0dW7lUB2TzTHbydSV uGQYsPQ93Lj47iR/r039GFk94oQcYuVsYe2G8krquwu9d00TeXtT5Bt3XpGq2Ol1u7LeOP gs2UTmOx+rrXKSDsoe+RBVp8wIFZjFw= 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-356-IJKDwiH0NK6bY1HRJtsNhg-1; Fri, 21 Oct 2022 18:13:12 -0400 X-MC-Unique: IJKDwiH0NK6bY1HRJtsNhg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D0BA585A59D; Fri, 21 Oct 2022 22:13:11 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E09B339D6A; Fri, 21 Oct 2022 22:13:10 +0000 (UTC) From: Florian Weimer To: Joseph Myers Cc: Subject: Re: C2x features status References: <874jvx81w2.fsf@oldenburg.str.redhat.com> Date: Sat, 22 Oct 2022 00:13:09 +0200 In-Reply-To: (Joseph Myers's message of "Fri, 21 Oct 2022 21:11:54 +0000") Message-ID: <874jvw7rm2.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 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.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Joseph Myers: > On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote: > >> Do you have a list of C2X features that are likely to impact autoconf >> tests? Or planned changes in the GCC 13 and 14 default language modes >> that reject constructs previous accepted as an extension? > > I think by far the biggest risk - for builds of old code in general, not= =20 > necessarily for autoconf tests - comes from the following two changes /= =20 > groups of changes: > > * Change of () in function declarations and definitions to mean (void), a= s=20 > in C++, instead of an unprototyped function. Hmm, I might need some help to create an instrumented GCC for that. Maybe keep the processing of declarations as-is, to tell () and (void) apart, but error out if a function declared without a prototype is called with one or more arguments? (The instrumentation works by recording certain errors in ways that an existing build system will not suppress. At the end of the build, we check that no such errors have occurred, otherwise the build is flagged for manual analysis. Curiously, it doesn't work that well for the original project, implicit function declarations=E2=80=94of course there ar= e some functions we do not implement and whose configure tests are expected to fail! But it should give good results for errors which really can't happen.) > * New keywords formerly in the user namespace: alignas alignof bool=20 > constexpr false nullptr static_assert thread_local true typeof=20 > typeof_unqual. (I haven't yet implemented C2x constexpr, but hope to get= =20 > to it for GCC 13. The others are all keywords now in C2x mode on GCC=20 > mainline.) Of these, by far the greatest risk is probably from bool,=20 > false and true, Thanks, I can probably fake this into the GCC-12-based compiler somehow. > while typeof was enabled by default for -std=3Dgnu* anyway=20 > in previous releases so is a lower risk. Do the semantics of typeof change to align with C++, so that typeof (int) becomes invalid? > There are also many new library functions, which obviously pose a risk to= =20 > programs using those identifiers for their own purposes and also includin= g=20 > the relevant header. I hope the risk from those is lower in general. =20 > Many of those aren't yet implemented in glibc; I've been focusing on=20 > compiler rather than library features during GCC development stage 1, and= =20 > also hoping to be able to wait for MPFR 4.2 to be released before=20 > implementing many of the new functions (to avoid=20 > gen-auto-libm-tests depending on an unreleased MPFR version). Historically, we haven't tracked breakage from changes like the new iszero macro proactively. I haven't seen silent autoconf test failures due to changes. Maybe we can fix issues as they result in build failures instead. Thanks, Florian