Well, they kept that quiet!

Well, they kept that quiet!

[Lucretia]

It's not on their blog yet, but they sneacked in this onto GitHub:

https://github.com/AdaCore/gnat-llvm

Will require the gprbuild from GitHub by the looks of it as well, unless you compilers.xml has support already inside for GNAT_LLVM as of June:

https://github.com/AdaCore/gprbuild/search?q=llvm&unscoped_q=llvm

This shall be interesting...

Re: Well, they kept that quiet!

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

> It's not on their blog yet, but they sneacked in this onto GitHub:
>
> https://github.com/AdaCore/gnat-llvm
>
> Will require the gprbuild from GitHub by the looks of it as well,
> unless you compilers.xml has support already inside for GNAT_LLVM as
> of June:
>
> https://github.com/AdaCore/gprbuild/search?q=llvm&unscoped_q=llvm
>
> This shall be interesting...

Indeed!

GNAT_LLVM is in gprbuild in the macOS 9.1.0 build I put on Sourceforge,
as well as in the macOS CE 2019.

Re: Well, they kept that quiet!

[Lucretia]

On Monday, 30 September 2019 17:34:13 UTC+1, Simon Wright  wrote:

> Indeed!
> 
> GNAT_LLVM is in gprbuild in the macOS 9.1.0 build I put on Sourceforge,
> as well as in the macOS CE 2019.


Yup.

I've added a new branch to free-ada for 9.2.0, as you need fsf gcc 9 to build this.

I've done a few quick tests with a null procedure.

$ llvm-gcc -c -mcpu=hawaii --target=amdgcn-amd-amdhsa- thang.adb
$ readelf -h thang.o 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 40 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            <unknown: 40>
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           AMD GPU
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          232 (bytes into file)
  Flags:                             0x23
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         6
  Section header string table index: 1

$ llvm-gcc -c --target=wasm32  thang.adb
$ file thang.o 
thang.o: WebAssembly (wasm) binary module version 0x1 (MVP)

:D

Re: Well, they kept that quiet!

[Optikos]

On Monday, September 30, 2019 at 8:09:04 AM UTC-5, Lucretia wrote:
> It's not on their blog yet, but they sneacked in this onto GitHub:
> 
> https://github.com/AdaCore/gnat-llvm
> 
> Will require the gprbuild from GitHub by the looks of it as well, unless you compilers.xml has support
> already inside for GNAT_LLVM as of June:
> 
> https://github.com/AdaCore/gprbuild/search?q=llvm&unscoped_q=llvm
> 
> This shall be interesting...

Well, for strict-GPLv3-licensed Ada-sourced apps & libraries, yes, gnat-llvm shall be interesting.  For everyone else for whom strict GPLv3 is unacceptable without the RLE's permission grants (and for whom AdaCore NDA/EULA licenses are cost prohibitive), this is merely an admirable historical reference for a possible future that has not yet come to fruition via a non-AdaCore Ada compiler.

as quoted from the webpage at the 1st URL above:

“License

“The GNAT LLVM tool is licensed under the GNU General Public License version 3 or later; see file COPYING3 for details.”

The COPYING3 file contains GPLv3 verbatim without any GMGPLv2- or RLE-esque permission grants.

The burning question will be:  will gnat-llvm ever be released in the future into FSF GNAT's source tree so that it has FSF's RLE permission grants?  Only AdaCore can answer that question.

Re: Well, they kept that quiet!

[Lucretia]

On Tuesday, 1 October 2019 15:58:41 UTC+1, Optikos  wrote:

> as quoted from the webpage at the 1st URL above:
> 
> “License
> 
> “The GNAT LLVM tool is licensed under the GNU General Public License version 3 or later; see file COPYING3 for details.”

That's the source of this LLVM binding, the compiler and runtime come from FSF and are under GPLv3 with linking exception. 

Then there's LLVM which actually generates the final code. The compiler links to the LLVM-C lib to generate an in memory AST which generates the LLVM IR which is then passed onto the LLVM tools, as/ld.

So, I think you could argue that the final code is a combination of GPLv3 with LE (the runtime) and whatever licence you want (your code).

> The COPYING3 file contains GPLv3 verbatim without any GMGPLv2- or RLE-esque permission grants.
> 
> The burning question will be:  will gnat-llvm ever be released in the future 
into FSF GNAT's source tree so that it has FSF's RLE permission grants?  Only AdaCore can answer that question.

AdaCore staff on IRC said "you'd be surprised" when I asked about licensing for this ages ago, hinting that it wouldn't all be covered by GPLv3 (no LE).

Re: Well, they kept that quiet!

[Simon Wright]

Lucretia <laguest9000@googlemail.com> writes:

> the compiler and runtime come from FSF and are under GPLv3 with
> linking exception

To be pedantic, the compiler is GPLv3, the runtimw is as you say.

Re: Well, they kept that quiet!

[Optikos]

On Tuesday, October 1, 2019 at 11:43:23 AM UTC-5, Lucretia wrote:
> On Tuesday, 1 October 2019 15:58:41 UTC+1, Optikos  wrote:
> 
> > as quoted from the webpage at the 1st URL above:
> > 
> > “License
> > 
> > “The GNAT LLVM tool is licensed under the GNU General Public License version 3 or later; see file
> > COPYING3 for details.”
> 
> That's the source of this LLVM binding, the compiler and runtime come from FSF and are under GPLv3 with linking exception. 
> 
> Then there's LLVM which actually generates the final code. The compiler links to the LLVM-C lib to
> generate an in memory AST which generates the LLVM IR which is then passed onto the LLVM tools,
> as/ld.

https://www.gnu.org/licenses/gcc-exception-3.1.html

There is a narrow path for gnat-llvm to walk gingerly along to preserve the RLE's Eligible Compilation Process permission grant when an app utilizes any portion of the FSF-sourced standard library, as shown by the embellishment of your sentence there:

The gnat-llvm compiler links to the LLVM-C lib to generate an •in memory WITHIN THE SAME PROCESS• AST which generates the LLVM IR •IN MEMORY WITHIN THE SAME PROCESS• which is then passed •IN MEMORY WITHIN THE SAME PROCESS• onto the LLVM tools as/ld/polly •THAT ARE LINKED INTO THE COMPILER AS THE SAME PROCESS AS THE COMPILER•.  If any of the •identified• portions are absent or flouted somehow, then gnat-llvm would naturally & obviously emit intermediate representation (IR) from the compiler to a disparate not-linked-to-the-gnat-llvm-compiler process, causing the federation of compilation processes* to no longer meet RLE's overtly-stated criteria for how to attain Eligible Compilation Process** status due to emitting IR as IPC or file(s) between the federation of compilation processes.  When an app is compiled by any federation of compilation processes that fails to meet RLE's overtly-stated criteria for Eligible Compilation Process, then the RLE's permission grant does not occur for that app that utilizes the FSF-sourced standard library, causing that app's generated object code and executable or DLL to be licensed under strict GPLv3 instead of GPLv3+RLE.

* plural!

** singular!

For gnat-llvm to always preserve the RLE's Eligible Compilation Process permission grant, then all portions of LLVM-world must be linked into 1 process, not IPC among 2 or more processes as is sometimes commonplace with e.g. polly:

http://releases.llvm.org/8.0.0/tools/polly/docs/HowToManuallyUseTheIndividualPiecesOfPolly.html

Manually executing polly as separate command lines as shown in the URL immediately above would clearly cause the federation of sequentially-executed processes* to no longer meet the RLE's definition of Eligible Compilation process**, hence causing the RLE's permission grant to not occur for object code and executable or DLL so generated, causing the generated object code and executable or DLL to be licensed under strict GPLv3 due to linking to the FSF-sourced standard library without the RLE's (now null & voided) permission grant.

* plural!

** singular!

Note however, executing polly •not manually• within the innards of a single compiler-invocation command line might perform a similar emission of IR as temporary files and a similar invocation of a sequence of disparate polly processes (i.e., where polly might*** not be linked entirely within 1 compiler executable), which taken together again would cause this sequentially-executed federation of compilation processes* to fail to meet RLE's overtly-stated definition of Eligible Compilation Process**, hence again causing the RLE's permission grant to not occur, hence again causing the binary object code and executable or DLL so generated to be licensed as strict GPLv3 without the RLE's (now null & voided) permission grant.

* plural!

** singular!

*** This needs to be verified by analysis of how polly actually is invoked •not manually• within a single compiler command line.  I used to be this way long ago, as I understand it, but I have re-verified in recent releases of Clang, polly, and now gnat-llvm.

> So, I think you could argue that the final code is a combination of GPLv3 with LE (the runtime) and
> whatever licence you want (your code).

The question isn't whether your •textual source• code has any desired license; the question is whether that •binary• app's usage of the FSF-source standard library has the RLE permission grant or not.

> > The COPYING3 file contains GPLv3 verbatim without any GMGPLv2- or RLE-esque permission grants.
> > 
> > The burning question will be:  will gnat-llvm ever be released in the future 
> into FSF GNAT's source tree so that it has FSF's RLE permission grants?  Only AdaCore can answer that
> question.
> 
> AdaCore staff on IRC said "you'd be surprised" when I asked about licensing for this ages ago, hinting
> that it wouldn't all be covered by GPLv3 (no LE).

I have never passed the bar in any legal jurisdiction.  This posting is a remembrance for me of my own understanding for my own usage and to motivate the reader to do their own analysis via their own reading of related materials.  If your activities in life depend on the veracity of any statements herein, then you should consult a lawyer in your system of law's jurisdiction instead of relying on statements herein.

Re: Well, they kept that quiet!

[Optikos]

On Wednesday, October 2, 2019 at 8:59:16 AM UTC-5, Optikos wrote:
> … all portions of LLVM-world must …

amendment:
… all portions of LLVM-world that contribute to IR generation or target†-code generation but not to source-to-source transforms must …

† as defined by the RLE

Re: Well, they kept that quiet!

[Simon Wright]

Optikos <optikos@verizon.net> writes:

> which is then passed •IN MEMORY WITHIN THE SAME PROCESS• onto the LLVM
> tools as/ld/polly •THAT ARE LINKED INTO THE COMPILER AS THE SAME
> PROCESS AS THE COMPILER•

No idea what polly is, but you are wrong about as & ld;

   '"Target Code" refers to output from any compiler for a real or
   virtual target processor architecture, in executable form or suitable
   for input to an assembler, loader, linker and/or execution phase.'

Re: Well, they kept that quiet!

[Optikos]

On Wednesday, October 2, 2019 at 11:37:23 AM UTC-5, Simon Wright wrote:
> Optikos writes:
> 
> > which is then passed •IN MEMORY WITHIN THE SAME PROCESS• onto the LLVM
> > tools as/ld/polly •THAT ARE LINKED INTO THE COMPILER AS THE SAME
> > PROCESS AS THE COMPILER•
> 
> No idea what polly is

Polly is the quite admirable polyhedral optimizer phases, and is the most-famous archetype representative of other IR-to-IR transforms in the LLVM ecosystem.  The LLVM ecosystem is well-known for having many more (and more sophisticated) IR-processing/reprocessing stages via plug-ins immediately ahead of the final as & ld step than GCC has or is capable of.  Because of the failure of GCC-XML vis a vis the contract-law IR complications of Eligible Compilation Process in GPLv3 RLE, GCC-world has had drastically fewer of these IR-to-IR value-added transforms.

> but you are wrong about as & ld

Obviously I am not talking about bland mundane ••unoptimized naïve•• Target Code being fed into as and ld with all value-adds turned off or inhibited in LLVM.  I am clearly referring to all the commonly-utilized actually-extant value-adds in the LLVM ecosystem that produce any kind of optimization or correctness-improving rewrite or any other value-add transform of the IR or of the IR-to-Target-Code generated that is then fed into as and ld, where as and ld are none the wiser that a prior stage improved the IR or the Target Code by rewriting it a little or a lot when compared to its bland/unoptimized/naïve/mundane starting point at an even earlier phase.  Your criticism is focusing (ridiculously) on the none-the-wiser part there at the input orifice of as and ld; I am focusing on the rewriting-it part there in that prior sentence immediately prior to feeding it into that orifice.  It is the rewriting-it part commonplace in the LLVM ecosystem that can very easily run afoul of the Eligible Compilation Process criteria in the RLE of GPLv3 (unless one assures a single compilation process without IPCing IR and without file-writing of IR or unless one is fine with strict GPLv3-without-RLE licensing for the generated object code and executable or DLL).

Because the phasing of LLVM-world's IR-transformation ecosystem is more complex than GCC's, the thinking and critical analysis also needs to be equally more complex to still meet the criteria of Eligible Compilation Process in GPLv3's RLE for linking to the FSF-sourced standard library.  Ignoring the ••intersection•• of 1) the technical details with 2) the contract-law details is not really an option (unless one actually wants strict GPLv3-without-RLE licensing for the generated object code and executable or DLL).

Re: Well, they kept that quiet!

[Lucretia]

On Wednesday, 2 October 2019 20:25:16 UTC+1, Optikos  wrote:

> > No idea what polly is
> 
> Polly is the quite admirable polyhedral optimizer phases, and is the most-famous archetype representative of other IR-to-IR transforms in the LLVM ecosystem.  The LLVM ecosystem is well-known for having many more (and more sophisticated) IR-processing/reprocessing stages via plug-ins immediately ahead of the final as & ld step than GCC has or is capable of.  Because of the failure of GCC-XML vis a vis the contract-law IR complications of Eligible Compilation Process in GPLv3 RLE, GCC-world has had drastically fewer of these IR-to-IR value-added transforms.

Polly is the LLVM eqivalent to GCC's Graphite, which isn't used any longer, AFAICS.

Re: Well, they kept that quiet!

[Simon Wright]

Optikos <optikos@verizon.net> writes:

> Obviously I am not talking about bland mundane ••unoptimized naïve••
> Target Code being fed into as and ld with all value-adds turned off or
> inhibited in LLVM.  I am clearly referring to all the
> commonly-utilized actually-extant value-adds in the LLVM ecosystem
> that produce any kind of optimization or correctness-improving rewrite
> or any other value-add transform of the IR or of the IR-to-Target-Code
> generated that is then fed into as and ld, where as and ld are none
> the wiser that a prior stage improved the IR or the Target Code by
> rewriting it a little or a lot when compared to its
> bland/unoptimized/naïve/mundane starting point at an even earlier
> phase.  Your criticism is focusing (ridiculously) on the
> none-the-wiser part there at the input orifice of as and ld; I am
> focusing on the rewriting-it part there in that prior sentence
> immediately prior to feeding it into that orifice.

I was going to write something rude, but instead I'll just disengage.