On Mon, 6 Mar 2017, Richard Biener wrote: > >I am not a lawyer and this is not legal advice. > > > >Generating SPIR-V output would not cause that output to become GPLv3 > >licensed. However, linking the result against the GCC support > >libraries, as is normally required for any program generated by GCC, > >and then distributing the resulting executable to other people, would > >require you to use an eligible compilation process (as defined by the > >GCC Runtime Library Exception license that you cite). What this means > >in practice is that you can not take SPIR-V, do further processing it > >using a proprietary compiler, link the result with the GCC runtime > >libraries, and then distribute the resulting program to anybody else. > > > >I don't think it is necessary to determine whether SPIR-V is "target > >code" or "intermediate representation" to draw that conclusion. > > Note we already have the HSAIL and PTX backends which have the very same > (non-)problem. Both invoke a proprietary compiler for final compilation.
Sorry, to me this statement sounds a bit ambiguous, so allow me to clarify: there is no mandatory invocation of proprietary code generators taking place as part of GCC invocation (I think there's none at all in case of HSAIL, and in case of PTX it's done for the purpose of syntax checking and can be omitted). Translation of HSAIL/PTX assembly to GPU binary code takes place when the host executable runs, on user's machine, by invoking corresponding libraries (in case of PTX it's NVIDIA's CUDA driver library). There is no support for translating HSAIL/PTX on the developer's machine and linking the resulting GPU binary code into GCC-produced executable. Hope that helps. Alexander
