From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:7891:: with SMTP id p139-v6mr1879545itc.40.1526582599976; Thu, 17 May 2018 11:43:19 -0700 (PDT) X-Received: by 2002:a9d:620d:: with SMTP id g13-v6mr2059otj.3.1526582599709; Thu, 17 May 2018 11:43:19 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.linkpendium.com!news.linkpendium.com!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no937292itc.0!news-out.google.com!b185-v6ni1080itb.0!nntp.google.com!v8-v6no937288itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 17 May 2018 11:43:19 -0700 (PDT) In-Reply-To: <1193667974.548270050.319144.laguest-archeia.com@nntp.aioe.org> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <9169bb0d-626f-4f6d-82c9-8a9b7543a084@googlegroups.com> <92b78739-e2c5-4e45-bbd8-f80ec4918691@googlegroups.com> <6dc39990-16eb-4717-8b8a-1d41c2767530@googlegroups.com> <1103700103.548265160.819002.laguest-archeia.com@nntp.aioe.org> <4a2e4dc5-aec6-4e59-91cd-9476abdbac7c@googlegroups.com> <1193667974.548270050.319144.laguest-archeia.com@nntp.aioe.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance From: "Dan'l Miller" Injection-Date: Thu, 17 May 2018 18:43:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52402 Date: 2018-05-17T11:43:19-07:00 List-Id: 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. =3D=3DPART 1=3D=3D Ah, here is the FAQ to which you are referring: it is the Runtime Exceptio= n FAQ, even though for the Target Code versus IR portion this FAQ effective= ly discusseses both GPLv3 itself (i.e., Target Code) intertwined with the R= untime Exception (i.e., Eligible Compilation Process). https://www.gnu.org/licenses/gcc-exception-3.1-faq.html I never said to =E2=80=A2extract=E2=80=A2 any IR via any kind of dump to fi= lesystem or sharing of DRAM with another process. I said to make LLVM bitc= ode 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 bit= code IR wouldn't be downstream [within the GPLv3ed GCC executable] from GIM= PLE, but would [within the GPLv3ed GCC executable] be downstream directly f= rom 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 =E2=80= =A2all=E2=80=A2 of LLVM subsumed into GCC (because the so-called MIT Licens= e, i.e., X11 License, is compatible with GPLv3). The entirety-of-LLVM-subs= umed-into-GCC-within-the-LLVM-bitcode-IR-as-ISA backend would produce all t= he actual hardware-processor machine-code targets that LLVM produces, emitt= ed as Target Code in (apparent?) full compliance with GPLv3 and its Runtime= Exception because LLVM would be housed within the single GCC executable (a= nd merely emitting garden-variety machine code for hardware processors). The question regarding GNAT IR becomes: how much is GNAT injecting _ARM_-d= efined Adaness when authoring either GENERIC (if it still is present) and/o= r GIMPLE, where that Adaness was =E2=80=A2absent=E2=80=A2 in GNAT semantica= lly-adorned-AST IR? =3D=3DPART 2=3D=3D 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=E2=80=94reportedly rather darned good LLVM bitcode IR. McS= ema =3D machine code semantics, a DARPA-funded project. Almost certainly t= his would be reverse engineering that is usually prohibited under EULAs. B= ut does lifting GCC's Target Code x86-executable output trigger the =E2=80= =9Cnotwithstanding that=E2=80=9D portion of the Runtime Exception: quoted from the Runtime Exception: =E2=80=9C"Target Code" refers to output from any compiler for a real or vir= tual target processor architecture, in executable form or suitable for inpu= t to an assembler, loader, linker and/or execution phase. =E2=80=A2Notwiths= tanding that=E2=80=A2, Target Code does not include data in any format that= is used as a compiler intermediate representation, or =E2=80=A2=E2=80=A2= =E2=80=A2=E2=80=A2used for =E2=80=A2producing=E2=80=A2 a compiler intermedi= ate representation=E2=80=A2=E2=80=A2=E2=80=A2=E2=80=A2.=E2=80=9D Does that clause mean that as soon as someone inputs GCC-produced would-hav= e-been-TargetCode into McSema that that x86-64 executable/library =E2=80=A2= ceases=E2=80=A2 (downstream) to be Target Code, reverting to an IR, even th= ough it is garden-variety Intel/AMD x86-64 machine code? Then causing ever= y (downstream) derivative work to be GPLv3ed (via GPLv3 itself) and Runtime= Exception revoked (downstream) and thus for good measured GPLv3ed again (v= ia 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 los= sy semantically.)