Hi! On Fri, 14 Aug 2015 16:56:25 +0000, Joseph Myers <jos...@codesourcery.com> wrote: > On Fri, 14 Aug 2015, Thomas Schwinge wrote: > > > This function »generate[s] a C source file containing a constructor call > > to GOMP_set_offload_targets [...], and adds that as an infile«. This > > "basically" works ;-) -- but really only for C source code, and for C++ > > and Fortran it fails if there are command-line options used that conflict > > with the C compilation of add-omp-infile, such as (from a libgomp > > testsuite run): for C++: -std=c++11, -fno-extern-tls-init, or for > > Fortran: -fcray-pointer, -fintrinsic-modules-path. Any suggestion about > > how to overcome that?
The "problem", as (I hope) I understand it, is that gcc/gcc.c:cc1_options
includes %{std*[...]} and %{f*}, which will match/accept the
C++/Fortran-specific command-line arguments (as cited above) even if
actually operating in C language mode for the add-omp-infile compilation.
> I suppose you need to use the option-handling information about which
> options are for which languages to filter out any options that aren't
> valid for C or Common.
OK, that sounds simple enough, conceptually. So, you are invalidating my
worry that the driver might in fact not be able to do this kind of thing
(mixed language compilation).
I'm currently trying to understand how all that command-line option
parsing code works, and the handoff from the driver to the frontends;
processing of the specs language.
Can you suggest off-hand where you'd expect this option filtering to
happen? Should this be during specs parsing in the driver; something
like adding a lang_mask to gcc/gcc.c:struct switchstr, and then in
gcc/gcc.c:give_switch ignore any switches that don't match the expected
CL_*? I seem to have difficulties to properly populate/deduce that
lang_mask at the call sites of gcc/gcc.c:save_switch. Or, did you
imagine that to be done differently?
Alternatively, what about changing gcc/opts-global.c:complain_wrong_lang
to silently ignore options that don't apply instead of emitting a »is
valid for [...] but not for [...]« diagnostic, if a (new) flag
(-f[something]?) has been set, which would be active only during the
add-omp-infile compilation?
Grüße,
Thomas
pgp8sVpxQ9Zgf.pgp
Description: PGP signature
