Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance

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

On Thursday, May 17, 2018 at 12:19:22 PM UTC-5, Luke A. Guest wrote:
> There is within the GPLv3 which states if you extract the
> ir from gcc in some way the resultant ir is gplv3. Like I said, see the
> faq.

==PART 1==
Ah, here is the FAQ to which you are referring:  it is the Runtime Exception FAQ, even though for the Target Code versus IR portion this FAQ effectively discusseses both GPLv3 itself (i.e., Target Code) intertwined with the Runtime Exception (i.e., Eligible Compilation Process).

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

I never said to •extract• any IR via any kind of dump to filesystem or sharing of DRAM with another process.  I said to make LLVM bitcode merely another ISA in the backend of GPLv3ed GCC, as if LLVM were a new hardware-processor IC.  (Then, I pondered an alternate form where LLVM bitcode IR wouldn't be downstream [within the GPLv3ed GCC executable] from GIMPLE, but would [within the GPLv3ed GCC executable] be downstream directly from GNAT IR in their semantically-adorned AST, but all that is still within a single GPLv3ed GCC executable without extract.)

The output of the LLVM-bitcode-IR-as-another-ISA backend would not be LLVM bitcode IR itself.  The LLVM-as-an-ISA backend would be the entirely •all• of LLVM subsumed into GCC (because the so-called MIT License, i.e., X11 License, is compatible with GPLv3).  The entirety-of-LLVM-subsumed-into-GCC-within-the-LLVM-bitcode-IR-as-ISA backend would produce all the actual hardware-processor machine-code targets that LLVM produces, emitted as Target Code in (apparent?) full compliance with GPLv3 and its Runtime Exception because LLVM would be housed within the single GCC executable (and merely emitting garden-variety machine code for hardware processors).

The question regarding GNAT IR becomes:  how much is GNAT injecting _ARM_-defined Adaness when authoring either GENERIC (if it still is present) and/or GIMPLE, where that Adaness was •absent• in GNAT semantically-adorned-AST IR?

==PART 2==
Btw, this brings up big-time another can of worms.  There is a lifter named McSema that takes any x86-64 executable (or library) as input and outputs LLVM bitcode IR—reportedly rather darned good LLVM bitcode IR.  McSema = machine code semantics, a DARPA-funded project.  Almost certainly this would be reverse engineering that is usually prohibited under EULAs.  But does lifting GCC's Target Code x86-executable output trigger the “notwithstanding that” portion of the Runtime Exception:

quoted from the Runtime Exception:
“"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. •Notwithstanding that•, Target Code does not include data in any format that is used as a compiler intermediate representation, or ••••used for •producing• a compiler intermediate representation••••.”

Does that clause mean that as soon as someone inputs GCC-produced would-have-been-TargetCode into McSema that that x86-64 executable/library •ceases• (downstream) to be Target Code, reverting to an IR, even though it is garden-variety Intel/AMD x86-64 machine code?  Then causing every (downstream) derivative work to be GPLv3ed (via GPLv3 itself) and Runtime Exception revoked (downstream) and thus for good measured GPLv3ed again (via the Runtime Exception revocation)?

(Btw, McSema strips all exception handling out, because currently it is too difficult, so in at least this regard the resulting LLVM bitcode IR is lossy semantically.)