This is the mail archive of the 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 <> 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

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

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


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]