public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Alexandre Oliva <oliva@adacore.com>
Cc: "Mike Stump" <mikestump@comcast.net>,
	gcc-patches@gcc.gnu.org,
	"Rainer Orth" <ro@cebitec.uni-bielefeld.de>,
	libstdc++@gcc.gnu.org, "Arsen Arsenović" <arsen@aarsen.me>
Subject: Re: testsuite: introduce hostedlib effective target
Date: Tue, 7 Nov 2023 10:24:47 +0000	[thread overview]
Message-ID: <CACb0b4mn81xdA_suTPTsuitwZDe8oYR8X2ZRSjF8A=nDzusN+w@mail.gmail.com> (raw)
In-Reply-To: <CACb0b4mMBSDSrP+eKExSMOT+cQH_fqKfhdXi_amkkVh0dd3LmA@mail.gmail.com>

On Tue, 7 Nov 2023 at 10:18, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Tue, 7 Nov 2023 at 10:04, Alexandre Oliva <oliva@adacore.com> wrote:
> >
> > [adding libstdc++@]
> >
> > On Nov  5, 2023, Mike Stump <mikestump@comcast.net> wrote:
> >
> > > Ick.
> >
> > Indeed ;-)
> >
> > > I wish there were fewer changed lines and not 1 per test
> > > case. It feels like we've painted ourselves into a corner.
> >
> > The libstdc++ testsuite took a different approach, detecting missing
> > headers (and libraries?) at error pruning time, and xfailing the tests,
> > which seems to be more in line with what you are looking for.
> >
> > That approach, though more expedient, seems more fragile to me, in that
> > an actual bug that caused headers to go missing would cause tests to be
> > silently skipped rather than fail.
>
> I don't think we XFAIL based on missing headers. We XFAIL based on a
> specific #error message in certain headers.
>
> If a header goes missing, we'll still XFAIL.
>
> >
> > I expect the set of headers, and thus of affected tests, won't by very
> > dynamic, so it's kind of a one-shot change.
> >
> > Of course new tests might be added that rely on such headers, and would
> > likely go unnoticed until someone tries them on a non-hosted libstdc++.
>
> Since GCC 13 you don't need to build a non-hosted libstdc++ to test
> it, you can just add -ffreestanding to the runtestflags.
>
> > We could alleviate this if libstdc++ headers that are not installed on
> > hosted systems issued a warning (conditional on some macro defined by
> > the testsuite, say -D_GLIBCXX_WARN_HOSTED_ONLY).
>
> That's exactly what happens (except #error not #warning) when you
> compile with -ffreestanding.
>
> >  For tests aimed
> > exclusively at hosted libstdc++, we'd then use a dg directive that both
> > implied this requirement, and changed the macro definition to suppress
> > the warning.  Then anyone who added a testcase that included hosted
> > headers without indicating its hostedlib requirement would get a fail
> > even when testing with a hosted libstdc++.
>
> I don't think we need to add checks for a new macro and then use that
> when testing, you can just test with -ffreestanding instead. This
> already works today.

Ah, reading back in the thread for  the context I missed, I see that
you're specifically testing a --disable-hosted-libstdcxx build. In
that case some headers really will be absent, not just
present-with-#error. But I am still not concerned about failing to
notice if a header goes unintentionally missing, because the libstdc++
testsuite will still notice that.

We don't prune based on "no such header" errors, so would still get
FAILs for those tests that depend on headers which are supposed to be
present for freestanding.


  reply	other threads:[~2023-11-07 10:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02  1:11 Alexandre Oliva
2023-11-05 20:40 ` Mike Stump
2023-11-07 10:04   ` Alexandre Oliva
2023-11-07 10:18     ` Jonathan Wakely
2023-11-07 10:24       ` Jonathan Wakely [this message]
2023-11-07 10:37         ` Jonathan Wakely
2023-11-08 15:30           ` Alexandre Oliva
2023-11-08 15:48             ` Jonathan Wakely
2023-11-08 15:49               ` Jonathan Wakely
2023-11-08 16:29   ` Alexandre Oliva
2023-11-09 21:42     ` Mike Stump

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='CACb0b4mn81xdA_suTPTsuitwZDe8oYR8X2ZRSjF8A=nDzusN+w@mail.gmail.com' \
    --to=jwakely@redhat.com \
    --cc=arsen@aarsen.me \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    --cc=mikestump@comcast.net \
    --cc=oliva@adacore.com \
    --cc=ro@cebitec.uni-bielefeld.de \
    /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).