This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFH] (3/3) Vectorize some builtins on x86_64 by using libgcc-math


On Fri, 17 Nov 2006, Joseph S. Myers wrote:

> On Fri, 17 Nov 2006, Richard Guenther wrote:
> 
> > Index: testsuite/lib/libgcc-math-dg.exp
> 
> This looks like it could have problems with installed toolchain testing.  
> With installed testing there is no build directory, but you don't need to 
> pass any special -B, -L etc. options or set LD_LIBRARY_PATH; instead the 
> user creates site.exp (with most of the variables gcc/Makefile.in puts 
> there, but not "rootme" or "TESTING_IN_BUILD_TREE") and arranges for the 
> compilers to be in the PATH and any necessary directories to be in 
> LD_LIBRARY_PATH, then runs "runtest --srcdir=whatever/testsuite 
> --tool=libgcc-math".  This should then run the compilers in the manner a 
> normal toolchain user would, rather than with lots of special options to 
> find things in the build tree.
> 
> Disabling most of the special handling if the appropriate directories 
> aren't found should suffice.  The libstdc++ testsuite definitely works for 
> installed testing.
> 
> > +     # Compute what needs to be put into LD_LIBRARY_PATH
> > +     set ld_library_path ".:${blddir}/.libs"
> 
> For example, don't do this if blddir wasn't found.

Ok, I guess the libgomp testsuite needs similar fixing.  I never have done
testing with an installed compiler, and using the site.exp generated by
gcc.dg testing and tying to use that it doesn't seem to work (removing
rootme and TESTING_IN_BUILD_TREE).  Instead I get

rguenther@murzim:/tmp/foofoo> runtest 
--srcdir=/space/rguenther/src/svn/trunk/gcc/testsuite --tool=gcc.dg
WARNING: Couldn't find tool init file
Test Run By rguenther on Fri Nov 17 13:51:29 2006
Native configuration is x86_64-unknown-linux-gnu

                === gcc.dg tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for 
target.
Using /space/rguenther/src/svn/trunk/gcc/testsuite/config/default.exp as 
tool-and-target-specific interface file.
Running 
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/charset/charset.exp 
...
ERROR: (DejaGnu) proc "gcc-set-multilib-library-path gcc" does not exist.
The error code is NONE
The info on the error is:
no files matched glob pattern 
"/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/gcc.dg*"
    while executing
"glob /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/gcc.dg*"
    invoked from within
"catch "glob ${path}/${pattern}" tmp"

                === gcc.dg Summary ===

the site.exp generated by the current libgcc-math variant is even more
terse and just contains

## these variables are automatically generated by make ##
# Do not edit here.  If you wish to override these values
# edit the last section
set srcdir /space/rguenther/src/svn/libgcc-math/libgcc-math/testsuite
set objdir 
/abuild/rguenther/libgcc-math/x86_64-unknown-linux-gnu/libgcc-math/testsuite
set build_alias "x86_64-unknown-linux-gnu"
set build_triplet x86_64-unknown-linux-gnu
set host_alias "x86_64-unknown-linux-gnu"
set host_triplet x86_64-unknown-linux-gnu
set target_alias "x86_64-unknown-linux-gnu"
set target_triplet x86_64-unknown-linux-gnu
## All variables above are generated by configure. Do Not Edit ##


So I'm confused as how this should work in general.  Supposed a
fresh bootstrapped and installed trunk was installed to /usr/local,
how would a site.exp and runtest invocation look like for testing
gcc.dg?

Thanks,
Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]