This is the mail archive of the gcc@gcc.gnu.org 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: GPLv3 clarification - what constitutes IR


On March 6, 2017 6:55:10 PM GMT+01:00, Alexander Monakov <amonakov@ispras.ru> wrote:
>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.

Yes, the final compilation taking part 'after' distribution might be a working loophole here.  Not sure if that was intended though (and both PTX and HSAIL and up being dynamically linked with libgomp).

I suppose some bits of clarifying documentation would be nice here.

Richard.

>Hope that helps.
>Alexander


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]