Re: DragonEgg has been revived

["Dan'l Miller" <optikos@verizon.net>]

On Wednesday, May 23, 2018 at 5:18:20 PM UTC-5, Chris M Moore wrote:
> On 23/05/2018 21:30, Dan'l Miller wrote:
> > Chris, you are fixated on one case in history.  The language of the Runtime Exception v3.1 that they authored is much broader than than one historical motivating case.  Just read the Runtime Exception v3.1 yourself and you will see that the word plug-in never appears at all.  Now imagine that all of LLVM and/or Polly outside of GCC is substantially equivalent to that non-GPLed plugin to GCC, but simply starts executing after a GCC compiler finishes executing by reading some sort of IR file written by GCC.  Whether it was an actual plug-in into an orifice within GCC matters not one whit.  What matters is whether a file that was not-Source-Code and not-Target-Code was written by GCC to feed into a downstream executable.
> 
> Apparently llvm is GPL compatible so dragonegg appears to be legal.  But 
> what you describe in the para above is what the what the Eligible 
> Compilation Process stuff was designed to prevent.

Oh, so the Runtime Exception actually is designed with legal teeth to prevent doing something, eh?  I am glad that you in your own mind finally convinced yourself that you have disproven the fallacious theorem to be disproven.  Q.E.D. by violent agreement, eh?  (See below for the original fallacious theorem from Simon to be disproven.)

> Simon W was saying that FSF gnat/gnat pro can produce non-GPLed 
> software.

  No, that is what I have been saying in prior comments in this thread:  in practice, what are actual encumbrances on the executables & DLLs written by FSF GNAT?  I listed 3.  Simon went further than that though to claim that there exist absolutely no restrictions related to GPLv3 on the executables and DLLs written by modern GCC.  Let us quote him to review:

shark8 wrote:
> What I would like to see is an Ada compiler that can generate code for 
> a wide range of targets ••without •any• GPL restrictions on the generated 
> code••. 

Simon Wright wrote:
> Pretty sure that's called GCC.

No, Simon, both Chris Moore and I have both shown that the Eligible Compilation Process prohibits certain categories of manipulations of the generated code, both code-in-the-form-of-true-IR and code-in-the-form-of-machine-code-lifted-back-to-IR-by-e.g.-McSema.  We are attacking your ignoring the “any” there in shark8's laudable expectation/goal.

>  It seems we can also do it via dragonegg.  But dumping the IR 
> to a file is not allowed.  I can't see how that's a restriction on the 
> target code generated as you asserted.

That is correct:  you don't see it.  McSema, Chris, McSema.  Read about the DARPA-funded lifter that lifts Target Code to LLVM bitcode IR, then read the “Target Code does not include data in •any format• that is … used for producing a compiler intermediate representation” and then re-read it 10 times while pondering that opcodes and their parameters in machine-code are mere data in a particular format.  “Any format that is … used for producing [IR]”.  (You really need to read less hearsay from 2009 about plug-ins and instead read current-era 2018 material.)