> -----Original Message-----
> From: Richard Biener <richard.guent...@gmail.com>
> Sent: Wednesday, July 14, 2021 2:19 PM
> To: Tamar Christina <tamar.christ...@arm.com>
> Cc: Michael Matz <m...@suse.de>; Bernd Edlinger
> <bernd.edlin...@hotmail.de>; Richard Biener <rguent...@suse.de>; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
>
> On Wed, Jul 14, 2021 at 3:15 PM Richard Biener
> <richard.guent...@gmail.com> wrote:
> >
> > On Wed, Jul 14, 2021 at 3:12 PM Richard Biener
> > <richard.guent...@gmail.com> wrote:
> > >
> > > On Wed, Jul 14, 2021 at 2:48 PM Tamar Christina via Gcc-patches
> > > <gcc-patches@gcc.gnu.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Ever since this commit
> > > >
> > > > commit c9114f2804b91690e030383de15a24e0b738e856
> > > > Author: Bernd Edlinger <bernd.edlin...@hotmail.de>
> > > > Date: Fri May 28 06:27:27 2021 +0200
> > > >
> > > > Various tools have been having trouble with cross compilation
> > > > resulting in
> > > >
> > > > make[2]: *** No rule to make target '../build-x86_64-build_pc-linux-
> gnu/libcpp/libcpp.a', needed by 'build/genmatch'.
> > > >
> > > > (took a while to track down). I don't understand this part of the build
> system well enough to know how to fix this.
> > > > It looks like `libcpp.a` has special handling for cross compilers which
> > > > now
> seems to be broken.
> > > >
> > > > I can't reproduce it with our normal cross compiler scripts. Which
> handles the stages on its own, but e.g.
> > > > https://github.com/crosstool-ng/crosstool-ng does reproduce the
> failure.
> > > >
> > > > Any ideas what's going on?
> > >
> > > There should be a dependence of all-gcc to all-build-libcpp,
> > > Makefile.def has
> > >
> > > dependencies = { module=all-gcc; on=all-build-libcpp; };
> > >
> > > so how come build-libcpp is not built when gcc/ starts?
> >
> > Ah, I guess (gcc/Makefile.in):
> >
> > CPPLIB = ../libcpp/libcpp.a
> > ...
> > # For stage1 and when cross-compiling use the build libcpp which is #
> > built with NLS disabled. For stage2+ use the host library and # its
> > dependencies.
> > ifeq ($(build_objdir),$(build_libobjdir))
> > BUILD_CPPLIB = $(build_libobjdir)/libcpp/libcpp.a
> > else
> > BUILD_CPPLIB = $(CPPLIB) $(LIBIBERTY)
> >
> > is not properly reflected in above dependences. Not sure how to fix
> > that though.
>
> I guess add
>
> dependencies = { module=all-gcc; on=all-libcpp; };
>
Isn't that already there? I see
dependencies = { module=all-gcc; on=all-libcpp; hard=true; };
already in Makefile.def
Regards,
Tamar
> like it is done for libiberty.
>
> > > > Kind Regards,
> > > > Tamar
> > > >
> > > > > -----Original Message-----
> > > > > From: Gcc-patches <gcc-patches-boun...@gcc.gnu.org> On Behalf Of
> > > > > Michael Matz
> > > > > Sent: Friday, May 28, 2021 4:33 PM
> > > > > To: Bernd Edlinger <bernd.edlin...@hotmail.de>
> > > > > Cc: gcc-patches@gcc.gnu.org; Richard Biener <rguent...@suse.de>
> > > > > Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c
> > > > > earlier
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Fri, 28 May 2021, Bernd Edlinger wrote:
> > > > >
> > > > > > >> I was wondering, why gimple-match.c and generic-match.c are
> > > > > > >> not built early but always last, which slows down parallel
> > > > > > >> makes significantly.
> > > > > > >>
> > > > > > >> The reason seems to be that generated_files does not
> > > > > > >> mention gimple-match.c and generic-match.c.
> > > > > > >>
> > > > > > >> This comment in Makefile.in says it all:
> > > > > > >>
> > > > > > >> $(ALL_HOST_OBJS) : | $(generated_files)
> > > > > > >>
> > > > > > >> So this patch adds gimple-match.c generic-match.c to
> generated_files.
> > > > > > >>
> > > > > > >>
> > > > > > >> Tested on x86_64-pc-linux-gnu.
> > > > > > >> Is it OK for trunk?
> > > > > > >
> > > > > > > This should help for what I was complaining about in
> > > > > > > https://gcc.gnu.org/pipermail/gcc/2021-May/235963.html . I
> > > > > > > build with
> > > > > > > -j24 and it was stalling on compiling gimple-match.c for me.
> > > > > > > Looks like insn-attrtab.c is missed too; I saw genattrtab
> > > > > > > was running last
> > > > > too.
> > > > > > >
> > > > > >
> > > > > > Yeah, probably insn-automata.c as well, sometimes it is picked
> > > > > > up early sometimes not. maybe $(simple_generated_c) should be
> > > > > > added to generated_files, but insn-attrtab.c is yet another
> exception.
> > > > >
> > > > > You can't put files in there that are sometimes slow to generate
> > > > > (which insn- {attrtab,automata}.c are on some targets), as
> > > > > _everything_ then waits for them to be created first.
> > > > >
> > > > > Ideally there would be a way for gnumake to mark some targets as
> > > > > "ugh- slow" and back-propagate this to all dependencies so that
> > > > > those are put in front of the work queue in a parallel make.
> > > > > Alas, something like that never came into existence :-/ (When
> > > > > order-only deps were introduced I got excited, but then came to
> > > > > realize that that wasn't what was really needed for this case, a
> > > > > "weak" version of it would be required at least, or better yet a
> > > > > specific facility to impose a cost with a target)
> > > > >
> > > > >
> > > > > Ciao,
> > > > > Michael.
> > > > >
> > > > > >
> > > > > >
> > > > > > Bernd.
> > > > > >
> > > > > > > Thanks,
> > > > > > > Andrew
> > > > > > >
> > > > > > >>
> > > > > > >>
> > > > > > >> Thanks
> > > > > > >> Bernd.
> > > > > > >>
> > > > > > >>
> > > > > > >> 2021-05-28 Bernd Edlinger <bernd.edlin...@hotmail.de>
> > > > > > >>
> > > > > > >> * Makefile.in (generated_files): Add gimple-match.c and
> > > > > > >> generic-match.c
> > > > > >
