This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GPLv3 clarification - what constitutes IR
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: Ian Lance Taylor <iant at google dot com>,Ian Lance Taylor via gcc <gcc at gcc dot gnu dot org>,laguest at mail dot com,help at softwarefreedom dot org,laguest at archeia dot com
- Date: Mon, 06 Mar 2017 19:03:31 +0100
- Subject: Re: GPLv3 clarification - what constitutes IR
- Authentication-results: sourceware.org; auth=none
- References: <trinity-180f0916-3b71-44db-8057-43cf8d8fd894-1488820351946@3capp-mailcom-lxa08> <CAKOQZ8wAe=RvnnHmMBi=oNKCBYkS3uXAFS7BzjhSmMWWfqyw-g@mail.gmail.com> <755C98CF-0062-48E4-B575-862481D60CB3@gmail.com> <alpine.LNX.2.20.13.1703062042010.2449@monopod.intra.ispras.ru>
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