public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mike Stump <mikestump@comcast.net>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Richard Henderson <rth@redhat.com>,
	gcc-patches@gcc.gnu.org,
	Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>,
	Janis Johnson <janisjo@codesourcery.com>
Subject: Re: libgomp testsuite: (not) using a specific driver for C++, Fortran?
Date: Tue, 04 Nov 2014 18:32:00 -0000	[thread overview]
Message-ID: <D735408D-F684-4083-920D-F47765B5B6A8@comcast.net> (raw)
In-Reply-To: <87y4rrrwnc.fsf@schwinge.name>

On Nov 4, 2014, at 4:13 AM, Thomas Schwinge <thomas@codesourcery.com> wrote:
> 
> On Wed, 15 Oct 2014 17:46:48 +0200, I wrote:
>> No matter whether it's C, C++, or Fortran source code, the libgomp
>> testsuite always uses (for build-tree testing) gcc/xgcc, or (for
>> installed testing) GCC_UNDER_TEST.  It doesn't make use of
>> GXX_UNDER_TEST, GFORTRAN_UNDER_TEST.  To support the latter two
>> languages' needs, some -l[...] flags are then added via lang_link_flags.
>> For example, for Fortran this is -lgfortran.  This is, however, not what
>> would happen if using the gfortran driver to build (which is what a user
>> would be doing -- which we should replicate as much as possible at least
>> for installed testing): the gfortran driver also adds -lquadmath, if
>> applicable.
>> 
>> Now, I wonder why to re-invent all that in the libgomp testsuite, if the
>> respective driver already has that knowledge, via spec files, for
>> example?  (Also, the regular GCC compiler tests, gcc/testsuite/, are
>> doing the right thing.)  Why is libgomp testsuite implemented this way --
>> just a legacy of the past, or is there a need for that (that I'm not
>> seeing)?
>> 
>> Maybe the question also is: why isn't the libgomp testsuite using more of
>> the infrastructure for specific languages, that is already implemented in
>> gcc/testsuite/lib/?  (That is, why does libgomp have to use
>> libgomp_target_compile, instead of [language]_target_compile, for
>> example.)
> 
> (I decided not to look into that latter idea, at the moment.)
> 
>> And maybe that problem also applied to additional target libraries'
>> testsuites; I have not yet looked.
> 
> (It does, but I'm not addressing that with the following patches.)
> 
>> Anyway, here is a prototype patch to describe how I began to address this
>> for the issue I stumbled upon, which is that the linker complained:
>> 
>>    Executing on host: x86_64-none-linux-gnu-gcc [...]/libgomp/testsuite/libgomp.fortran/aligned1.f03 [...] -fopenmp   -O0  -fopenmp -fcray-pointer   -lgfortran -lm   -o ./aligned1.exe    (timeout = 300)
>>    [...]/ld: warning: libquadmath.so.0, needed by [...]/libgfortran.so, not found (try using -rpath or -rpath-link)
>>    [...]/libgfortran.so: undefined reference to `logq@QUADMATH_1.0'
>>    [...]
>> 
>> (That goes away if I add -lquadmath to the command line, but that's not
>> the point I'm making here.)
>> 
>> Am I on the right track with the following?
> 
> Nobody commented, which also means nobody disagreed

:-)

> OK to commit all that to trunk?

Ok, thanks.

If you could, one minor point, s/puts/verbose “boa bla“ <N>/   I know it was preexisting.

I wonder if any variables that you set that need to be cleared out are, that seems a defect in the api or conventions we use and it can screw following tests with a wrong environment in subtle ways.  I could miss accidental bleed over from the .exp you’re modifying into other unrelated parts of the test suite.  Usually, we just try and be careful and clean it up if it breaks.

Watch for any review points from the libgomp people, they might trickle a few in.  I don’t mean to cut short any review points from them.

Also, please watch for breakage.

  reply	other threads:[~2014-11-04 18:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15 15:52 Thomas Schwinge
2014-11-04 12:14 ` Thomas Schwinge
2014-11-04 18:32   ` Mike Stump [this message]
2023-05-09 12:36     ` libgomp C++ testsuite: Don't compute 'blddir' twice (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?) Thomas Schwinge
2023-05-09 12:39       ` libgomp testsuite: Only use 'blddir' if set (was: libgomp C++ testsuite: Don't compute 'blddir' twice (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?)) Thomas Schwinge
2023-05-09 12:41         ` libgomp testsuite: Use 'lang_test_file_found' instead of 'lang_test_file' (was: libgomp testsuite: Only use 'blddir' if set (was: libgomp C++ testsuite: Don't compute 'blddir' twice (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?))) Thomas Schwinge
2023-05-09 12:54     ` libgomp testsuite: Localize 'lang_[...]' etc. (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?) Thomas Schwinge
2023-05-09 12:59       ` libgomp C++, Fortran testsuites: Resolve 'lang_test_file_found' first (was: libgomp testsuite: Localize 'lang_[...]' etc. (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?)) Thomas Schwinge
2023-05-09 13:05         ` libgomp testsuite: Get rid of 'lang_test_file_found' (was: libgomp C++, Fortran testsuites: Resolve 'lang_test_file_found' first (was: libgomp testsuite: Localize 'lang_[...]' etc. (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?))) Thomas Schwinge
2023-05-12  7:26     ` libgomp testsuite: Generalize 'lang_library_path' into a list of 'lang_library_paths' (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?) Thomas Schwinge
2023-05-12  8:27     ` libgomp testsuite: Have each '*.exp' file specify the compiler to use [PR91884] " Thomas Schwinge
2023-05-12  8:33       ` libgomp testsuite: As appropriate, use the 'gcc', 'g++', 'gfortran' driver [PR91884] (was: libgomp testsuite: Have each '*.exp' file specify the compiler to use [PR91884] (was: libgomp testsuite: (not) using a specific driver for C++, Fortran?)) Thomas Schwinge

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=D735408D-F684-4083-920D-F47765B5B6A8@comcast.net \
    --to=mikestump@comcast.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=janisjo@codesourcery.com \
    --cc=ro@CeBiTec.Uni-Bielefeld.DE \
    --cc=rth@redhat.com \
    --cc=thomas@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).