This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFH] (3/3) Vectorize some builtins on x86_64 by using libgcc-math
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
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
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.
Joseph S. Myers