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, 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
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 Guenther <firstname.lastname@example.org>
Novell / SUSE Labs