Hi Bernd! On Fri, 9 Oct 2015 14:43:24 +0200, Bernd Schmidt <bschm...@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
signature.asc
Description: PGP signature
