This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Offloading: libgfortran, libm dependencies


Hi Bernd!

On Fri, 9 Oct 2015 14:43:24 +0200, Bernd Schmidt <bschmidt@redhat.com> 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

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]