public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Tamar Christina <Tamar.Christina@arm.com>
Cc: Michael Matz <matz@suse.de>,
	Bernd Edlinger <bernd.edlinger@hotmail.de>,
	 Richard Biener <rguenther@suse.de>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Generate gimple-match.c and generic-match.c earlier
Date: Wed, 14 Jul 2021 15:15:22 +0200	[thread overview]
Message-ID: <CAFiYyc1XiEMx_7si_00NwZnkLaXsbUaFWnS3j2tTuQTE2J2VBw@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc3UjEE5MrxXfc0FLhBR6g=ZzhPQX8XqzTMwz861xN22pw@mail.gmail.com>

On Wed, Jul 14, 2021 at 3:12 PM Richard Biener
<richard.guenther@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.edlinger@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.

> > Kind Regards,
> > Tamar
> >
> > > -----Original Message-----
> > > From: Gcc-patches <gcc-patches-bounces@gcc.gnu.org> On Behalf Of
> > > Michael Matz
> > > Sent: Friday, May 28, 2021 4:33 PM
> > > To: Bernd Edlinger <bernd.edlinger@hotmail.de>
> > > Cc: gcc-patches@gcc.gnu.org; Richard Biener <rguenther@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.edlinger@hotmail.de>
> > > > >>
> > > > >>         * Makefile.in (generated_files): Add gimple-match.c and
> > > > >>         generic-match.c
> > > >

  reply	other threads:[~2021-07-14 13:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-28  4:42 Bernd Edlinger
2021-05-28  4:51 ` Bernd Edlinger
2021-05-28  6:41   ` Richard Biener
2021-05-28  6:48     ` Bernd Edlinger
2021-05-28  7:26 ` Andrew Pinski
2021-05-28  7:33   ` Bernd Edlinger
2021-05-28  8:48     ` Jakub Jelinek
2021-05-28 15:33     ` Michael Matz
2021-07-14 12:47       ` Tamar Christina
2021-07-14 13:12         ` Richard Biener
2021-07-14 13:15           ` Richard Biener [this message]
2021-07-14 13:19             ` Richard Biener
2021-07-14 13:25               ` Tamar Christina
2021-07-14 15:56         ` Bernd Edlinger
2021-07-14 16:47           ` Tamar Christina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFiYyc1XiEMx_7si_00NwZnkLaXsbUaFWnS3j2tTuQTE2J2VBw@mail.gmail.com \
    --to=richard.guenther@gmail.com \
    --cc=Tamar.Christina@arm.com \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=matz@suse.de \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).