From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12015 invoked by alias); 4 Nov 2014 18:32:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 12004 invoked by uid 89); 4 Nov 2014 18:32:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: resqmta-ch2-11v.sys.comcast.net Received: from resqmta-ch2-11v.sys.comcast.net (HELO resqmta-ch2-11v.sys.comcast.net) (69.252.207.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 04 Nov 2014 18:32:47 +0000 Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-11v.sys.comcast.net with comcast id BWYg1p00D2VvR6D01WYloa; Tue, 04 Nov 2014 18:32:45 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-ch2-19v.sys.comcast.net with comcast id BWYh1p00W2ztT3H01WYi7H; Tue, 04 Nov 2014 18:32:43 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: libgomp testsuite: (not) using a specific driver for C++, Fortran? From: Mike Stump In-Reply-To: <87y4rrrwnc.fsf@schwinge.name> Date: Tue, 04 Nov 2014 18:32:00 -0000 Cc: Jakub Jelinek , Richard Henderson , gcc-patches@gcc.gnu.org, Rainer Orth , Janis Johnson Content-Transfer-Encoding: quoted-printable Message-Id: References: <87h9z5wd1z.fsf@schwinge.name> <87y4rrrwnc.fsf@schwinge.name> To: Thomas Schwinge X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00219.txt.bz2 On Nov 4, 2014, at 4:13 AM, Thomas Schwinge wrote: >=20 > 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. >>=20 >> 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)? >>=20 >> 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.) >=20 > (I decided not to look into that latter idea, at the moment.) >=20 >> And maybe that problem also applied to additional target libraries' >> testsuites; I have not yet looked. >=20 > (It does, but I'm not addressing that with the following patches.) >=20 >> 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: >>=20 >> 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 =3D 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' >> [...] >>=20 >> (That goes away if I add -lquadmath to the command line, but that's not >> the point I'm making here.) >>=20 >> Am I on the right track with the following? >=20 > 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 =93boa bla=93 / I know i= t was preexisting. I wonder if any variables that you set that need to be cleared out are, tha= t seems a defect in the api or conventions we use and it can screw followin= g tests with a wrong environment in subtle ways. I could miss accidental b= leed over from the .exp you=92re modifying into other unrelated parts of th= e test suite. Usually, we just try and be careful and clean it up if it br= eaks. Watch for any review points from the libgomp people, they might trickle a f= ew in. I don=92t mean to cut short any review points from them. Also, please watch for breakage.