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 202EA3858D3C for ; Wed, 19 Oct 2022 08:40:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 202EA3858D3C 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=1666168814; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=eI2dwGICMVLAXtNRMb7qb1oSLpqg0SRsxQ9p7QDQQq0=; b=ABcgHbyxNAd2XYr1LL0QsXUZy26BNIhCbtRuuVmVtG5LN1t9vSGkvmEsc9xnthH3tPRdlR dq3BwjGSBo8xW1xGOl7EgkJCDNqb48+WBDTgdB8bHU+OApXBnhe9mGNCh8PrD7lxuarbBA 0Ne8VFSjTvW7WlPsEllZbTNXGB8DsPA= 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-484-co7tyZwsO4q8ACz3idNE4A-1; Wed, 19 Oct 2022 04:40:13 -0400 X-MC-Unique: co7tyZwsO4q8ACz3idNE4A-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 3BB631C09B70 for ; Wed, 19 Oct 2022 08:40:13 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.193.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EA805492B05; Wed, 19 Oct 2022 08:40:12 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 29J8eA5G3797285 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 19 Oct 2022 10:40:10 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29J8eAwp3797284; Wed, 19 Oct 2022 10:40:10 +0200 Date: Wed, 19 Oct 2022 10:40:09 +0200 From: Jakub Jelinek To: Jason Merrill , Jonathan Wakely Cc: gcc@gcc.gnu.org Subject: [RFC] c++, libstdc++: Default make check vs. tests for newest C++ standard Message-ID: Reply-To: Jakub Jelinek 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=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.2 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: Hi! The screw-up on my side with libstdc++ testing (tested normally rather than in C++23 mode) makes me wonder if we couldn't tweak the default testing. Dunno what libstdc++ testing normally does (just C++17?), make check-g++ tests by default { 98, 14, 17, 20 } (and I regularly use GXX_TESTSUITE_STDS=98,11,14,17,20,2b in environment but that doesn't cover libstdc++ I guess). When adding tests for upcoming C++ version, one always has a dilemma whether to use explicit // { dg-options "-std=c++2b" } or -std=gnu++2b and similar, then the test works in all modes, but it might be forgotten later on to be converted into // { dg-do whatever { target c++23 } } test so that when 23 is tested by default and say 26 or 29 appears too, we test it also in those modes, or just go with // { dg-do whatever { target c++23 } } which has the disadvantage that it is skipped when testing by default and one only tests it if he asks for the newer version. I wonder if we couldn't for the default testing (when one doesn't specify GXX_TESTSUITE_STDS or uses make check-c++-all and similar) improve things a little bit by automatically treat those // { dg-do whatever { target c++23 } } tests as // { dg-options "-std=c++2b" }. g++-dg.exp has: # If the testcase specifies a standard, use that one. # If not, run it under several standards, allowing GNU extensions # if there's a dg-options line. if ![search_for $test "-std=*++"] { if [search_for $test "dg-options"] { set std_prefix "-std=gnu++" } else { set std_prefix "-std=c++" } # See g++.exp for the initial value of this list. global gpp_std_list if { [llength $gpp_std_list] > 0 } { set std_list $gpp_std_list } else { set std_list { 98 14 17 20 } } set option_list { } foreach x $std_list { # Handle "concepts" as C++17 plus Concepts TS. if { $x eq "concepts" } then { set x "17 -fconcepts" } elseif { $x eq "impcx" } then { set x "23 -fimplicit-constexpr" } lappend option_list "${std_prefix}$x" } } else { set option_list { "" } } set nshort [file tail [file dirname $test]]/[file tail $test] foreach flags_t $option_list { verbose "Testing $nshort, $flags $flags_t" 1 dg-test $test "$flags $flags_t" ${default-extra-flags} } so I wonder if in the set std_list { 98 14 17 20 } spot we couldn't do something like special search_for for "{ dg-do * { target c++23 } }" and if so, set std_list { 2b } instead of set std_list { 98 14 17 20 }? It wouldn't handle more complex cases like // { dg-do compile { target { c++23 && { aarch64*-*-* powerpc64le*-*-linux* riscv*-*-* s390*-*-* sparc*-*-linux* } } } } but at least for the majority of tests for the new language version it would run them even in default testing where they'd be otherwise skipped (we'd cycle over 98 14 17 20 only to see it doesn't satisfy any of them). If we wanted to go even further, we could handle similarly say c++11_only tests. What do you think? Jakub