public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>, Jonathan Wakely <jwakely@redhat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: [RFC] c++, libstdc++: Default make check vs. tests for newest C++ standard
Date: Wed, 19 Oct 2022 09:10:48 -0400	[thread overview]
Message-ID: <2bfe4f0a-84cc-aae8-1834-6dff3918810a@redhat.com> (raw)
In-Reply-To: <Y0+36fGnYINE/VJN@tucnak>

On 10/19/22 04:40, Jakub Jelinek wrote:
> 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" }.

That would be great.

> 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
> 


      parent reply	other threads:[~2022-10-19 13:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19  8:40 Jakub Jelinek
2022-10-19  8:54 ` Jonathan Wakely
2022-10-19 13:10 ` Jason Merrill [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2bfe4f0a-84cc-aae8-1834-6dff3918810a@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jwakely@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).