On Mon, 2022-05-30 at 18:09 +0800, Xi Ruoyao wrote: > Ping. I'd like to see libgccjit working on LoongArch so I would be > able > to submit a Rust port to upstream. > > If the result is NACK I'd like to know alternative approaches to fix > the > build failure. > > I doubt if "j...@gcc.gnu.org" is really used, so CC'ed the JIT > maintainer > listed in MAINTAINERS.
Sorry about that, it turns out there's something wrong with my email filters. Unfortunately, I haven't been able to fix them, so please CC me directly on jit-related patches, and do ping me if I seem not to have seen one. Sorry again. > > On Thu, 2022-05-19 at 16:10 +0800, Yang Yujie wrote: > > Hello, > > > > This patch fixes libgccjit build failure on loongarch* targets, > > and could probably be useful for future ports. > > > > For now, libgccjit is linked with objects from $(EXTRA_GCC_OBJS) > > and > > libbackend.a, which contains object files from $(EXTRA_OBJS). > > > > This effectively forbids any overlap between those two lists, i.e. > > all > > target-specific shared code between the gcc driver and compiler > > executables must go into gcc/common/config/<arch>/<arch>-common.cc, > > which feels a bit inconvenient when there are a lot of "common" > > stuff > > that we want to put into separate source files. > > > > By linking libgccjit with $(EXTRA_GCC_OBJS_EXCLUSIVE), which > > contains > > all elements from $(EXTRA_GCC_OBJS) but not $(EXTRA_OBJS), this > > problem > > can be alleviated. Yujie: thanks for figuring this out, and coming up with a solution. Presumably libgccjit is the only GCC "frontend" that also has driver code directly linked into it, and thus the only one that needs this workaround. > > > > This patch does not affect any other target architecture than > > loongarch, > > and has been bootstrapped and regression-tested on loongarch64- > > linux- > > gnuf64 > > an x86_64-pc-linux-gnu. > > > > Any recommendations? Please review. Thanks a lot. The patch looks good to me. Thanks. Dave > > > > Yujie > > > > * gcc/jit/ChangeLog: > > > > * Make-lang.in: only link objects from $(EXTRA_GCC_OBJS) > > that's not in $(EXTRA_OBJS) into libgccjit. > > --- > > gcc/jit/Make-lang.in | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in > > index 6e10abfd0ac..248ec45b729 100644 > > --- a/gcc/jit/Make-lang.in > > +++ b/gcc/jit/Make-lang.in > > @@ -157,18 +157,23 @@ LIBGCCJIT_EXTRA_OPTS = > > $(LIBGCCJIT_VERSION_SCRIPT_OPTION) \ > > endif > > endif > > > > +# Only link objects from $(EXTRA_GCC_OBJS) that's not already > > +# included in libbackend.a ($(EXTRA_OBJS)). > > +EXTRA_GCC_OBJS_EXCLUSIVE = $(foreach _obj1, $(EXTRA_GCC_OBJS), \ > > + $(if $(filter $(_obj1), $(EXTRA_OBJS)),, $(_obj1))) > > + > > # We avoid using $(BACKEND) from Makefile.in in order to avoid > > pulling > > # in main.o > > $(LIBGCCJIT_FILENAME): $(jit_OBJS) \ > > libbackend.a libcommon-target.a libcommon.a \ > > $(CPPLIB) $(LIBDECNUMBER) \ > > $(LIBDEPS) $(srcdir)/jit/libgccjit.map \ > > - $(EXTRA_GCC_OBJS) $(jit.prev) > > + $(EXTRA_GCC_OBJS_EXCLUSIVE) $(jit.prev) > > @$(call LINK_PROGRESS,$(INDEX.jit),start) > > +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ -shared \ > > $(jit_OBJS) libbackend.a libcommon-target.a > > libcommon.a \ > > $(CPPLIB) $(LIBDECNUMBER) $(EXTRA_GCC_LIBS) $(LIBS) > > $(BACKENDLIBS) \ > > - $(EXTRA_GCC_OBJS) \ > > + $(EXTRA_GCC_OBJS_EXCLUSIVE) \ > > $(LIBGCCJIT_EXTRA_OPTS) > > @$(call LINK_PROGRESS,$(INDEX.jit),end) > > >
