On Thu, 10 Sep 2015, Bernd Schmidt wrote: > On 09/10/2015 03:41 PM, Joseph Myers wrote: > > Ping^2. This patch > > <https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01748.html> is still > > pending review. > > No fundamental objections, but I have some questions. Cuold you describe > what the handling of flags/lang_mask accomplishes in this patch? Would > option handling be simpler if the creation/compilation of the extra file > happened in lto_wrapper (where we already do similar things through > mkoffload)?
The point of the lang_mask handling is that if, say, we're compiling C++ or Fortran code, with options that aren't valid for C, we mustn't pass those options to cc1 when building the constructor as C code, but we do still need to pass options valid for C (which might e.g. affect the ABI). There's an argument that this sort of option filtering should be done more generally. That is, if we have a mixed-language compilation in a single call to the driver, it should filter the options so that cc1 gets those options applicable for C, cc1plus those applicable to C++, etc., with options for inappropriate languages only being diagnosed if none of the source files are for that language. I don't know if that's the right thing to do or not, but it's at least plausible. I don't see lto-wrapper as being any easier as a place to do this; no doubt lto-wrapper or collect2 could create the file and call back into the driver to compile it, but I don't see the advantage in doing that over having the driver (which already has all the relevant information, since it's coming from the command line rather than inspection of object files being linked) do it. > I initially thought the information you're giving to > GOMP_set_offload_targets is already available implicitly, from the calls > to GOMP_offload_register. But digging through the archives it sounds > like the problem is that if there's no offloadable code, no offload > image will be generated. Is that correct? Yes. In the message Thomas referred to, "On the other hand, for example, for -foffload=nvptx-none, even if user program code doesn't contain any offloaded data (and thus the offload machinery has not been run), the user program might still contain any executable directives or OpenACC runtime library calls, so we'd still like to use the libgomp nvptx plugin. However, we currently cannot detect this situation.". -- Joseph S. Myers jos...@codesourcery.com
