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

[Richard Guenther <rguenther at suse dot de>]

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

> On Fri, 17 Nov 2006, Richard Guenther wrote:
> 
> > Ok, I guess the libgomp testsuite needs similar fixing.  I never have done
> 
> Quite possibly.  I know that gcc, g++ and libstdc++ work (after Mark fixed 
> problems in them), and when I tried it recently gfortran worked (with no 
> fixes needed, results identical to built-tree testing).
> 
> > 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?
> 
> site.exp (in directory /where/you/are/running/the/testsuite)
> 
> set CC i686-pc-linux-gnu-gcc
> set CXX i686-pc-linux-gnu-g++
> set host_triplet i686-pc-linux-gnu
> set host i686-pc-linux-gnu
> set target_triplet i686-pc-linux-gnu
> set target_alias i686-pc-linux-gnu
> set HOSTCC "i686-pc-linux-gnu-gcc"
> set HOSTCFLAGS ""
> set LIBS ""
> set libiconv ""
> set tmpdir /where/you/are/running/the/testsuite
> 
> runtest command:
> 
> cd /where/you/are/running/the/testsuite && runtest --tool gcc \
>   --srcdir $gcc_srcdir/gcc/testsuite --target_board="unix"
> 
> Before running runtest, you should have set PATH so that the compilers to 
> test are in the PATH, and LD_LIBRARY_PATH so that programs they build can 
> be run.  PATH=/usr/local/bin:$PATH; export LD_LIBRARY_PATH=/usr/local/lib
> 
> That command will run the whole gcc testsuite.  To run just dg.exp, add 
> "dg.exp" (or maybe "dg.exp=*.c") to the end of the command line, to run 
> just foo.c from dg.exp add "dg.exp=foo.c".  Change "--tool gcc" to "--tool 
> g++" to run the g++ testsuite instead.  Use "--tool libstdc++ --srcdir 
> $gcc_srcdir/libstdc++-v3/testsuite" to run the libstdc++ testsuite.  Look 
> at any of the .log files generated and notice how much simpler the 
> compilation command lines are than those from build-tree testing (and how 
> much more like command lines compiler users might actually use).
> 
> 
> There is the view that each directory should install to a staging area 
> within the build tree, that "make install" should just copy this area to 
> $prefix and that build-tree testing should just run the compilers from 
> this area like installed testing and rely on the compiler's ability to 
> find all the pieces of itself when relocated.  That would substatially 
> simplify the testing infrastructure, because *no* testsuite would then 
> need to know anything about how to locate bits of the compiler in the 
> build tree (instead of all testsuites needing to locate them at present), 
> all would just presume that running $target-gcc just works and can find 
> the libraries just as it would when installed.  But we're a very long way 
> from that at present.

Thanks, that helped!  (Any chance of getting this information in
http://gcc.gnu.org/install/test.html?)

I now can test from inside the build tree as well as with an installed
compiler.  Now onto the gcc.dg/vect issue... (if only libgcc were in the
toplevel already, this would provide me with a case to copy from...)

Richard.

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