public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
	Jakub Jelinek <jakub@redhat.com>,
	       Thomas Schwinge <thomas@codesourcery.com>,
	       Mike Stump <mikestump@comcast.net>,
	       Joseph Myers <joseph@codesourcery.com>
Subject: Re: [libgomp][testsuite] PR testsuite/91884 Add -lquadmath if available
Date: Wed, 09 Oct 2019 13:19:00 -0000	[thread overview]
Message-ID: <ydd36g2jc7a.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <d4468b7e-8a90-f625-de49-4fe912f6b423@codesourcery.com> (Tobias	Burnus's message of "Wed, 9 Oct 2019 10:18:13 +0200")

Hi Tobias,

> I have also an alternative version:
>
> * For in-build-dir test runs, do as with previous patch, i.e. add
> "-lquadmath" to the "xgcc" call if the directory is available.
>
> * For installed-compiler test runs, the new patch uses GFORTRAN_UNDER_TEST
> / GXX_UNDER_TEST
> (It would also use them with in-build-dir runs, but nothing sets them. I
> have kept the -lgfortran / -lstdg++ flags, though they could be left out
> iff {GXX,GFORTRAN}_UNDER_TEST is set. Presumably, some linker will complain
> if they appear twice.)

TBH, this whole dance of always using xgcc/gcc and repeating everything
the real language drivers (xg++/g++ resp. gfortran) and their spec files
do and know in the testsuite seems extremly fragile.  The only variant
that makes sense to me is one letting the correct drivers do their work
(as is done e.g. in single-language lib testing like libstdc++) and have
the testsuite provide the necessary -L and -B flags for in-tree builds.

While this how I believe things should work, I've been practically
unable to do any useful testsuite patch review let alone testsuite work
for quite some time, so take this with a large grain of salt...  The
testsuite as a whole is riddled with immense amounts of duplication and
diverging almost-copies of code.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

      reply	other threads:[~2019-10-09 13:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-08 18:33 Tobias Burnus
2019-10-09  7:49 ` Jakub Jelinek
2019-10-09  8:47   ` Tobias Burnus
2019-10-09  8:20 ` Tobias Burnus
2019-10-09 13:19   ` Rainer Orth [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=ydd36g2jc7a.fsf@CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=mikestump@comcast.net \
    --cc=thomas@codesourcery.com \
    --cc=tobias@codesourcery.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).