public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: Jonathan Wakely <jwakely@redhat.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: Wed, 08 Nov 2023 12:30:05 -0300	[thread overview]
Message-ID: <or5y2cjm9u.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <CACb0b4mu+kcbU-Y2BUC778T87VXZ20sdi6JHw-XCPtR2SSA6mQ@mail.gmail.com> (Jonathan Wakely's message of "Tue, 7 Nov 2023 10:37:10 +0000")

On Nov  7, 2023, Jonathan Wakely <jwakely@redhat.com> wrote:

> An alternative approach for the g++ testsuite would be to provide a
> set of dummy headers for the non-freestanding ones, so that all the
> hosted-only headers are provided by the testsuite itself, but consist
> of a single line:

> #error not available in freestanding

> Then match on that and XFAIL. So the individual tests themselves
> wouldn't need the dg-skip-if added to them, they would just
> automatically XFAIL if they use a hosted-only header.

*nod*.  That wouldn't cover all the circumstances, alas: there are tests
that fail in freestanding mode not because of headers, but because
-fcontracts (currently?) links libstdc++exp in, and that library is not
even built in freestanding mode.

> The difficulty would be where to add those dummy headers for
> <iostream>, <cstdio> etc. so that they're only found when testing a
> non-hosted build. Maybe libstdc++ could provide them in the build dir
> for the purposes of the testsuite, but not install them?

We run install-tree testing, so that wouldn't quite work for us.  If the
headers are in some subdirectory in the source tree, that we (or the
testsuite machinery) would just add to the -I set, that would help.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

  reply	other threads:[~2023-11-08 15:30 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
2023-11-07 10:37         ` Jonathan Wakely
2023-11-08 15:30           ` Alexandre Oliva [this message]
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=or5y2cjm9u.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=arsen@aarsen.me \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=mikestump@comcast.net \
    --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).