On Sun, 2022-06-26 at 14:06 +0100, Iain Sandoe wrote:
> Hi Dave, folks,
> 
> It seems to me that it is plausible that one could use the JIT in a
> heterogenous system, e.g. an x86_64-linux-host with some kind of co-
> processor which is supported as a GCC target (and therefore can be
> loaded with jit-d code) … but I’m not aware of anyone actually doing
> this?

libgccjit is horribly misnamed, in that it can also be used for ahead-
of-time compilation; I wish I'd called it libgcccodegen or somesuch. 
So a more plausible use-case for cross-compilation with libgccjit is
(ahem) the non-jit case.  I'd like to support this, but I have to
confess that I'm not experienced in setting up a full cross-compilation
toolchain; my cross-compilation testing of GCC has been limited to
configuring with --target and verifying by hand that sane-looking asm
is emitted.

The heterogeneous system might also be doable, but the ahead-of-time
cross-compilation seems much more important.

> 
> .. is that use case even reasonable given the current implementation?
> (I guess there are invocations of the assembler etc. .. I’m not sure
> if these would work as currently implemented)
> 
> ----
> 
> It’s mildly inconvenient that the build for cross compilers generally
> fails for me on Darwin (reason 1 below) since I tend to configure by
> default with —enable-languages=all (and most Darwin platform versions
> default to host_shared).  So I’d like to see what the best way
> forward is …..
> 
> ----
> 
> In the short-term there are some issues with the configuration for
> cross-compilers…
> 
> 1) the values queried in gcc/jit/Make-lang.in relate to the ‘ld’ that
> is used for $target not the one used for $host.
> 
>  - this means that if we are on a $host with an non-binutils-ld and
> building a cross-compiler for a $target that *does* use binutils-ld,
> the configuration selects flags that do not work so that the build
> fails.
>  - of course, things might fail more subtly in the case that there
> were two *different* binutils ld instances.
> 
> 2) the testsuite obviously does not work.
> 
> So .. one possibility is to disable jit for cross-compilers, (patch
> attached) .. 
> 
> … another is to find a way to fix the configuration to pick up
> suitable values for $host (although I’m not sure how much of that we
> have readily available, since usually libtool is doing that work).

FWIW I'd prefer to get it working, but I probably lack the experience
with cross-compilation to do that, alas.

Sorry that this isn't the most helpful answer
Dave

Reply via email to