Re: Missing dependency in Ada build?

[Alan Lawrence]

On 07/10/15 18:33, Eric Botcazou wrote:

So it looks like there are two problems here:
(1) xsinfo not terminating;
(2) a missing dependency, that the g++ steps should depend upon the step
producing sinfo.h (i.e. the mv that comes after problem (1))

I'm going to look at (1), but I'm hoping someone more familiar with the Ada
build system might be able to help with regards to (2)?


Try to replace $(GNAT1_ADA_OBJS) with $(GNAT1_OBJS) in the line:

# When building from scratch we don't have dependency files, the only thing
# we need to ensure is that the generated files are created first.
$(GNAT1_ADA_OBJS) $(GNATBIND_OBJS): | $(ada_generated_files)

in ada/gcc-interface/Make-lang.in.



Yes, that fixes the dependency problem; the build waits for the xsinfo to 
terminate. This at least makes it easy to Ctrl-C and try again. Are we aware of 
any reason why *not* to make that change?


The hang in xsinfo appears to be miscompilation when the host compiler is 
gnat-4.8 (on ARM), whereas gnat-4.6 succeeds. I'm going to try again with later 
versions (4.9/5.0/etc.)...


Thanks, Alan

Re: Offloading: libgfortran, libm dependencies

[Bernd Schmidt]

On 10/02/2015 05:20 PM, Thomas Schwinge wrote:

How should we handle libgfortran and libm dependencies in offloaded code?

As the linking requirements especially regarding libgfortran may be
different for each offloading target (shared and/or static libraries
supported, static linking enforced, libquadmath needed, and so on), I
think the specific configuration must happen inside the offloading
execution path (mkoffload).  Thus, trying to do this inside the gfortran
front end, gcc/fortran/gfortranspec.c:lang_specific_driver etc., does not
appear to be doing it the right way; for offloaded code, we'll always be
using the lto1 front end instead of the gfortran one.  Is a libgfortran
link spec like libgomp's, together with some flag (similar to
-fopenmp/-fopenacc being used with the libgomp link spec) the right thing
to do?


So I think I'm following your reasoning, and what you suggest may well 
be the best solution. The question then becomes how to decide when to 
pass that new flag. Have f951 put it into the options written into LTO 
somehow?



Bernd

Re: Offloading: libgfortran, libm dependencies

[Thomas Schwinge]

Hi Bernd!

On Fri, 9 Oct 2015 14:43:24 +0200, Bernd Schmidt  wrote:
> On 10/02/2015 05:20 PM, Thomas Schwinge wrote:
> > How should we handle libgfortran and libm dependencies in offloaded code?
> >
> > As the linking requirements especially regarding libgfortran may be
> > different for each offloading target (shared and/or static libraries
> > supported, static linking enforced, libquadmath needed, and so on), I
> > think the specific configuration must happen inside the offloading
> > execution path (mkoffload).  Thus, trying to do this inside the gfortran
> > front end, gcc/fortran/gfortranspec.c:lang_specific_driver etc., does not
> > appear to be doing it the right way; for offloaded code, we'll always be
> > using the lto1 front end instead of the gfortran one.  Is a libgfortran
> > link spec like libgomp's, together with some flag (similar to
> > -fopenmp/-fopenacc being used with the libgomp link spec) the right thing
> > to do?
> 
> So I think I'm following your reasoning, and what you suggest may well 
> be the best solution.

Thanks for looking into this!

> The question then becomes how to decide when to 
> pass that new flag. Have f951 put it into the options written into LTO 
> somehow?

That's indeed one idea that I had.  Something like this: the respective
front ends add -flanguage-fortran (etc.) options, which in the following
then can be used in specs files to have each target configuration do the
appropriate thing (which is, somewhat, what's doing for
-fopenacc/-fopenmp).

Maybe with something like that, quite some logic could be moved from
gcc/fortran/gfortranspec.c:lang_specific_driver into the respective spec
files/strings?

Maybe (as a later step?) such -flanguage-* options should even be
generated inside the GCC driver proper, gcc/gcc.c, which sounds like a
good step into the direction of supporting mixed-language compilation
(where you can't have both the, say, cc1plus and f951 front ends add the
-lstdc++ and -lgfortran options, respectively)?

Are all such -f* options written into the LTO options stream already, so
the effort for handling that aspect should be relatively minor?

I still don't have the best understanding of GCC's driver/spec
files/options handling, so I'd still appreciate more review on this
design.


Grüße,
 Thomas


signature.asc
Description: PGP signature