public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mike Stump <mikestump@comcast.net>
To: Alexandre Oliva <oliva@adacore.com>
Cc: gcc-patches@gcc.gnu.org, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
Subject: Re: testsuite: introduce hostedlib effective target
Date: Sun, 5 Nov 2023 12:40:59 -0800	[thread overview]
Message-ID: <600FDF8F-67C5-408F-BD24-9A3964A8BFA1@comcast.net> (raw)
In-Reply-To: <ormsvxnemj.fsf@lxoliva.fsfla.org>

On Nov 1, 2023, at 6:11 PM, Alexandre Oliva <oliva@adacore.com> wrote:
> 
> Several C++ tests fail with --disable-hosted-libstdcxx, whether
> because stdc++ext gets linked in despite not being built, because
> standard headers are included but that are unavailable in this mode,
> or because headers are (mistakenly?) expected to introduce
> declarations such as for ::abort, but in this mode they don't.
> 
> This patch introduces an effective target for GCC test, equivalent to
> one that's available in the libstdc++-v3 testsuite, and arranges for
> all such tests to be skipped when libstdc++-v3 is not hosted.
> 
> This patch was tested with arm-eabi, with libstdc++-v3 configured with
> --disable-hosted-libstdcxx, on gcc-13, and with x86_64-linux-gnu
> likewise on trunk.  In the latter, there are a number of additional
> fails that appear to be related, and that I'm yet to investigate, but
> this is big enough already, so I figured I'd post this and see whether
> the approach is regarded as sound and acceptable before proceeding any
> further.  WDYT?  Ok to install, to deal with other targets
> incrementally?

Ick.  I wish there were fewer changed lines and not 1 per test case. It feels like we've painted ourselves into a corner.

That said, I'd rather have a nice solid game plan that is better and suggest it over this approach but, the best I can think of it something that can notice after the fact during an error, and during error processing, trim or expect, which is awfully vague.

So, instead of commenting more, I'd ask if anyone has a nice, good concrete idea and say I want to withdraw from the vague.

If someone comes up with something you think is better, easy, smaller and or other goodness and you want to go that direction, I'd encourage that, otherwise, I'll approve this version.


  reply	other threads:[~2023-11-05 20:41 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 [this message]
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
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=600FDF8F-67C5-408F-BD24-9A3964A8BFA1@comcast.net \
    --to=mikestump@comcast.net \
    --cc=gcc-patches@gcc.gnu.org \
    --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).