On Mon, 2015-01-19 at 10:51 +0100, Richard Biener wrote: > On Fri, Jan 16, 2015 at 7:47 PM, David Malcolm <dmalc...@redhat.com> wrote: > > On Thu, 2015-01-15 at 22:50 +0100, Richard Biener wrote: > >> On January 15, 2015 9:05:59 PM CET, David Malcolm <dmalc...@redhat.com> > >> wrote: > >> >Release managers: given that this only touches the jit, and that the > >> >jit > >> >is off by default, any objections if I go ahead and commit this? > >> >It's a late-breaking feature, but the jit as a whole is new, and > >> >I think the following is a big win, so I'd like to proceed with this in > >> >stage 3 (i.e. in the next 24 hours). There are docs and testcases. > >> > > >> >New jit API entrypoint: gcc_jit_context_compile_to_file > >> > > >> >This patch adds a way to use libgccjit for ahead-of-time compilation. > >> >I noticed that given the postprocessing steps the jit has to take to > >> >turn the .s file into in-memory code (invoke driver to convert to > >> >a .so and then dlopen), that it's not much of a leap to support > >> >compiling the .s file into objects, dynamic libraries, and executables. > >> > > >> >Doing so seems like a big win from a feature standpoint: people with > >> >pre-existing frontend code who want a backend can then plug in > >> >libgccjit > >> >and have a compiler, without needing to write it as a GCC frontend, or > >> >use LLVM. > >> > >> Note that you should make them aware of our runtime license with > >> respect to the eligible compilation process. Which means this is not > >> a way to implement proprietary front ends. > >> > >> Richard. > > > > IANAL, but as I understand things, the runtime license is an additional > > grant of rights that covers certain components of GCC that bear the GCC > > Runtime Library Exception, allowing them to be used in certain > > additional ways beyond regular GPLv3-compliance. > > > > libgccjit doesn't have that exception; it's GPLv3. > > > > Perhaps an argument could be made for libgccjit to have the exception, > > if the FSF think that that would better serve the FSF's mission; right > > now, I'm merely trying to provide a technical means to modularity. > > > > Assuming the above is correct, anything linked against it needs to be > > GPLv3-compatible. Hence any such frontend linked against libgccjit > > would need to be GPLv3-compatible. > > > > Attached is a patch (on top of the proposed one below), to clarify the > > wording in the new tutorial a little, to remind people that such linking > > needs to be license-compatible (without actually spelling out what the > > license is, though it's visible at the top of the public header file, > > libgccjit.h, as GPLv3 or later without the runtime library exception). > > > > Are the combined patches OK by you? > > Yes. > > Thanks, > Richard.
Thanks. I've committed the combination of the two patches to trunk as r219876. Sorry about the lateness of this feature. With this commit, gcc now has a brainf*** frontend (albeit one hidden deep in the jit examples dir, and not using the regular frontend machinery). Dave
