GPLv3 clarification - what constitutes IR
Hi, I'm looking into the possibility of adding a SPIR-V (https://www.khronos.org/registry/spir-v) backend to GCC or as a plug-in. The output of which would be binary from the compiler, not binutils, with an option to extract a textual representation using an -f flag. The positive of this would be that any language that GCC supports could be used for GPGPU and graphics shading. But would the GCC IR exception (mentioned in https://www.gnu.org/licenses/gcc-exception-3.1-faq.html) cause any SPIR-V output from GCC become GPLv3 licenced? I have also posted this to the GCC ML for discussion as I don't think it's clear whether or not something like SPIR-V would fall under Target Code or IR. Thanks, Luke A. Guest. P.S: I currently cannot post from my domain for some reason. I don't know why.
Re: GPLv3 clarification - what constitutes IR
On Mon, Mar 6, 2017 at 9:12 AM, wrote: > > I'm looking into the possibility of adding a SPIR-V > (https://www.khronos.org/registry/spir-v) backend to GCC or as a > plug-in. The output of which would be binary from the compiler, not > binutils, with an option to extract a textual representation using an -f > flag. The positive of this would be that any language that GCC supports > could be used for GPGPU and graphics shading. > > But would the GCC IR exception (mentioned in > https://www.gnu.org/licenses/gcc-exception-3.1-faq.html) cause any > SPIR-V output from GCC become GPLv3 licenced? > > I have also posted this to the GCC ML for discussion as I don't think > it's clear whether or not something like SPIR-V would fall under Target > Code or IR. 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. Ian
Re: GPLv3 clarification - what constitutes IR
On March 6, 2017 6:29:49 PM GMT+01:00, Ian Lance Taylor via gcc wrote: >On Mon, Mar 6, 2017 at 9:12 AM, wrote: >> >> I'm looking into the possibility of adding a SPIR-V >> (https://www.khronos.org/registry/spir-v) backend to GCC or as a >> plug-in. The output of which would be binary from the compiler, not >> binutils, with an option to extract a textual representation using an >-f >> flag. The positive of this would be that any language that GCC >supports >> could be used for GPGPU and graphics shading. >> >> But would the GCC IR exception (mentioned in >> https://www.gnu.org/licenses/gcc-exception-3.1-faq.html) cause any >> SPIR-V output from GCC become GPLv3 licenced? >> >> I have also posted this to the GCC ML for discussion as I don't think >> it's clear whether or not something like SPIR-V would fall under >Target >> Code or IR. > >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. Richard. >Ian
Re: GPLv3 clarification - what constitutes IR
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
Re: GPLv3 clarification - what constitutes IR
On March 6, 2017 6:55:10 PM GMT+01:00, Alexander Monakov 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
terminology: zero character vs. null character
Hi, I am currently translating GCC into German. During that, I noticed that in some places the term "zero character" means '\0'. The official term though is "null character", as per the C standard. Since it is confusing to have two different terms for the same concept, the term "zero character" should be dropped entirely, both because it is uncommon and because it can be confused with '0'. Since this affects several places in the code, I think it's better to start a small discussion first instead of writing several PRs. Regards, Roland
SPEC 456.hmmer vectorization question
I was looking at the spec 456.hmmer benchmark and this email string from Jeff Law and Micheal Matz: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01970.html and was wondering if anyone was looking at what more it would take for GCC to vectorize the loop in P7Viterbi. There is a big performance win to be had here if it can be done but the alias checking needed seems rather extensive. Steve Ellcey sell...@cavium.com
Re: gcc-7-20170305 is now available
On Sun, 5 Mar 2017, gccad...@gcc.gnu.org wrote: > gcc-7-20170305.tar.bz2 Complete GCC > > SHA256=ea44ed9c765acacf3ae03a33ea386e70af98f51e97f4506c5bc7b54ded56d19e > SHA1=b9fcd2b9d68753f32234c7e21fef94ef0c91d419 Please note that I changed from MD5 and SHA1 hashes for snapshots to SHA256 and SHA1 hashes last week. (If you have been using a command m5sum or similar to verify the checksum so far, now you can use "openssl sha256", for example.) Let me know if you have any questions or issues. Gerald
Re: gcc-7-20170305 is now available
On Mär 07 2017, Gerald Pfeifer wrote: > (If you have been using a command m5sum or similar to verify the > checksum so far, now you can use "openssl sha256", for example.) There is also sha256sum, which has a more regular output. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
