Re: [PATCH] Avoid the need to install when running the jit testsuite

2014-10-17 Thread Joseph S. Myers
On Fri, 17 Oct 2014, David Malcolm wrote:

> +# This symlink makes the full installation name of the driver be available
> +# from within the *build* directory, for use when running the JIT library
> +# from there (e.g. when running its testsuite).
> +$(FULL_DRIVER_NAME): ./xgcc
> + $(LN) -s $< $@

I believe $(LN_S) would be normal, though (a) I don't see it being used 
anywhere, despite the definition, and (b) while the GNU Coding Standards 
still say "If you use symbolic links, you should implement a fallback for 
systems that don't have symbolic links." I'm doubtful that's of practical 
relevance to systems people are building GCC on any more.

I don't have any comments on the other parts of this patch.

-- 
Joseph S. Myers
jos...@codesourcery.com


[PATCH] Avoid the need to install when running the jit testsuite

2014-10-17 Thread David Malcolm
On Wed, 2014-10-15 at 17:29 -0400, David Malcolm wrote:
> On Wed, 2014-10-15 at 14:51 -0600, Jeff Law wrote:
> > On 10/15/14 12:25, David Malcolm wrote:
> > > On Wed, 2014-10-15 at 11:36 -0600, Jeff Law wrote:
> > >> On 10/13/14 11:45, David Malcolm wrote:
> > >>> gcc/ChangeLog:
> > >>> * configure.ac (gcc_version): Expose this value for use via
> > >>> AC_SUBST, since the jit code needs it within the new file
> > >>> libgccjit.pc.in.
> > >>> (doc_build_sys): New variable, set to "sphinx" if
> > >>> sphinx is installed, falling back to "texinfo" otherwise.
> > >>> (gcc-driver-name.h): Generate a gcc-driver-name.h file 
> > >>> containing
> > >>> GCC_DRIVER_NAME for the benefit of jit/jit-playback.c.
> > >>> * configure: Regenerate.
> > >>> * Makefile.in (doc_build_sys): New.
> > >>> (bindir): New.
> > >>> (pkgconfigdir): New.
> > >>> (installdirs): Add creation of $(DESTDIR)$(pkgconfigdir).
> > >>> (site.exp): When constructing site.exp, add a line to set 
> > >>> "bindir".
> > >> Mostly OK.  Though a couple questions.
> > >>
> > >> Why do we need pkgconfig and why do you need a bindir in site.exp?
> 
[...snip pkg-config discussion...]

> > As for the "bindir" in site.exp, Joseph asked me when the library
> > > invokes a driver to convert from .s to .so to:
> > >
> > > On Tue, 2014-09-23 at 23:27 +, Joseph S. Myers wrote:
> > >> * use the $(target_noncanonical)-gcc-$(version) name for the
> > >> driver rather than plain "gcc", to maximise the chance that it
> > >> is actually the same compiler the JIT library was built for (I
> > >> realise you may not actually depend on it being the same
> > >> compiler, but that does seem best; in principle in future it
> > >> should be possible to load multiple copies of the JIT library
> > >> to JIT for different targets, so that code for an offload
> > >> accelerator can go through the JIT).
> > > ( https://gcc.gnu.org/ml/jit/2014-q3/msg00033.html )
> > >
> > > This full name is used when *installing* the driver, but doesn't exist
> > > within the build directory.
> > > Hence when running the library, the installation bindir needs to be in
> > > the PATH.  In particular, (in
> > > https://gcc.gnu.org/ml/jit/2014-q4/msg5.html ) when running the jit
> > > testsuite we rely on the driver having been installed, and in jit.exp we
> > > need to temporarily prepend the installation bindir onto the front of
> > > PATH when running test programs linked against libgccjit.so.  Hence we
> > > need to know what bindir is from expect, hence we add it to site.exp.
> > So if I'm reading all this correctly, what's being implied is that 
> > testing is done using the installed bits rather than the in-build-tree 
> > bits?  We really need this to run without having been installed.
> 
> One approach here might be to do make a copy of the driver binary with
> the final name within the *build* dir (e.g.
> "x86_64-unknown-linux-gnu-gcc-5.0.0").
> 
> Another might be the "run the driver code in-process" approach I dabbled
> with here:
>   https://gcc.gnu.org/ml/jit/2014-q3/msg00049.html
> though that's some way from working, and is more invasive (no-one
> replied to that email)

The first approach seems to work well, and avoids the need to
"make install" before running the testsuite.

Jeff, Joseph: how does the following look?  (not yet committed to the
branch)

Avoid discrepancy between the installed name of the driver as used
by libgccjit (e.g. "x86_64-unknown-linux-gnu-gcc-5.0.0") and that
within the builddir by adding a simple symlink to xgcc within the
builddir, with the install-time name.

When running the testsuite, set PATH and LIBRARY_PATH when invoking
built binaries that use libgccjit so that it can find the driver, and so
that when the driver invokes the linker, the linker can find libgcc,
libgcc_s, crtbeginS.o, etc, finding them all in the builddir via "xgcc"
via libgloss.

This avoids the need for installation when running the testsuite, whilst
avoiding "baking in" any paths into the built library.

This patch doesn't touch the documentation (I plan to do that as a
followup).

gcc/ChangeLog.jit:
* Makefile.in (FULL_DRIVER_NAME): New variable, adapted from the
install-driver target.  New target, a symlink within the builddir,
linked to "xgcc", for use when running the JIT library from the
builddir.
(MOSTLYCLEANFILES): Add FULL_DRIVER_NAME.
(install-driver): Use $(FULL_DRIVER_NAME) rather than spelling it
out.
(site.exp): Don't set "bindir", as this is no longer needed when
running the jit testsuite.

gcc/jit/ChangeLog.jit:
* Make-lang.in (jit): Add $(FULL_DRIVER_NAME) as a dependency, so
that the symlink is created for testing.

* jit-playback.c (gcc::jit::playback::context::compile): Add
"-fno-use-linker-plugin" when invoking the driver.  Update error
messag