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