On Nov 4, 2014, at 4:13 AM, Thomas Schwinge <tho...@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.
