* [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)
@ 2022-05-19 8:10 Yang Yujie
2022-05-30 10:09 ` Xi Ruoyao
0 siblings, 1 reply; 4+ messages in thread
From: Yang Yujie @ 2022-05-19 8:10 UTC (permalink / raw)
To: gcc-patches, jit; +Cc: xuchenghua, Yang Yujie
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.
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.
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)
--
2.31.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)
2022-05-19 8:10 [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS) Yang Yujie
@ 2022-05-30 10:09 ` Xi Ruoyao
2022-06-06 22:33 ` David Malcolm
0 siblings, 1 reply; 4+ messages in thread
From: Xi Ruoyao @ 2022-05-30 10:09 UTC (permalink / raw)
To: Yang Yujie, gcc-patches, jit; +Cc: xuchenghua, David Malcolm
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 "jit@gcc.gnu.org" is really used, so CC'ed the JIT maintainer
listed in MAINTAINERS.
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.
>
> 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.
>
> 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)
>
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)
2022-05-30 10:09 ` Xi Ruoyao
@ 2022-06-06 22:33 ` David Malcolm
2022-06-08 6:49 ` Xi Ruoyao
0 siblings, 1 reply; 4+ messages in thread
From: David Malcolm @ 2022-06-06 22:33 UTC (permalink / raw)
To: Xi Ruoyao, Yang Yujie, gcc-patches, jit; +Cc: xuchenghua
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 "jit@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)
> >
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)
2022-06-06 22:33 ` David Malcolm
@ 2022-06-08 6:49 ` Xi Ruoyao
0 siblings, 0 replies; 4+ messages in thread
From: Xi Ruoyao @ 2022-06-08 6:49 UTC (permalink / raw)
To: David Malcolm, Yang Yujie, gcc-patches, jit; +Cc: xuchenghua
On Mon, 2022-06-06 at 18:33 -0400, David Malcolm wrote:
> > On Thu, 2022-05-19 at 16:10 +0800, Yang Yujie wrote:
> > > 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.
Pushed as r13-1010.
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-06-08 6:50 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-19 8:10 [PATCH v2] libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS) Yang Yujie
2022-05-30 10:09 ` Xi Ruoyao
2022-06-06 22:33 ` David Malcolm
2022-06-08 6:49 ` Xi Ruoyao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).