From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 44AF7385840A; Tue, 15 Aug 2023 11:04:58 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 44AF7385840A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1692097498;
	bh=F1vpcMqfhiWMqA6uL+ZuVFJy3fOSV1Ec9m/U7KsCEWM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=OPu3MSWpwU18LulZng0NlApEAgxVZWT9iUGzn9JKJwkug4zW3kNz6p9DgH/K5YO/0
	 Yf5l+PUG6VYPPpBjg6IzbKWs2YNX96aYk2MJxmzHRgz7CSaBdCEJosiU9UN3wB8o3X
	 GCE/XMmlvYZR+qjlT4CpxguwMjWxQcuApTzKKZC8=
From: "hp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/111021] [14 Regression] Serial build broken for CRIS,
 ARM, and others
Date: Tue, 15 Aug 2023 11:04:57 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hp at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111021-4-rq9xItGG6y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111021-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111021-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111021

--- Comment #17 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> I think a "too broad" dependence isn't bad.  The cris specific solution a=
lso
> looks manageable, though I wonder what's special about x-protos.h, knowing
> very little of that area.

Not very special, it's just that there's a now dependence on tree.h and its
generated contents where for tm-protos.h there has been none before.  The
reasons seem avoidable at this time, but I think it's nominally valid to ha=
ve
that dependency.  On the one hand, introducing a new dependency where there=
 has
been none before and dealing with the fallout we now see is awkward, but on=
 the
other hand pragmatically the dependence on tree.h for $(TM_P) is trivial en=
ough
that a parallel build "raced" to fulfill it. IOW, shouldn't affect build ti=
me
by any measure.

(Not closing this PR yet in case maintainers go forward for the other
tm-protos.h-affected targets)=