From: Jakub Jelinek <jakub@redhat.com>
To: Richard Earnshaw <richard.earnshaw@arm.com>,
Richard Sandiford <richard.sandiford@arm.com>,
Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] aarch64: Fix aarch64-tune.md (re)generation [PR105144]
Date: Mon, 4 Apr 2022 11:04:48 +0200 [thread overview]
Message-ID: <Ykq0sF7HVQnyTzp0@tucnak> (raw)
Hi!
As I wrote in the PR, our Fedora trunk gcc builds likely after r12-7842
change are now failing (lto1 crashes).
What happens is that when one bootstraps into an empty build directory
(or set of them), mddeps.mk doesn't exist yet and so Makefile doesn't
include it. When building from an empty dir, that is usually not a big
issue, it is enough when various build directory files depend on just
$(srcdir)/config/aarch64/aarch64.md, those files don't exist and
aarch64.md does, so they are built, so is mddeps.mk.
But because the other dependencies aren't there (in particular
$(srcdir)/config/aarch64/aarch64-tune.md ), the
s-aarch64-tune-md rule isn't invoked to regenerate that file and the
r12-7842 commit reordered aarch64-cores.def entries but didn't commit
regenerated aarch64-tune.md. Because it is just reordering in
aarch64-tune.md, it actually doesn't matter and bootstraps succeeds.
But then during make install, mddeps.mk exists already in gcc/ directory,
it sees that aarch64-cores.def is newer than aarch64-tune.md (unless
gen_update is used, that just touches aarch64-tune.md to make sure it
is newer) and regenerates it and as it is different, make install rebuilds
a large subset of the *.o files, but this time with the system g++
rather than previous stage one. And during lto linking of it there
are differences in LTO bytecode between the compilers and we crash.
The following patch fixes that by regenerating aarch64-tune.md
(what was forgotten in r12-7842) and by adding a dependency from
s-mddeps to s-aarch64-tune-md, which makes sure that even when mddeps.mk
doesn't exist yet make sees the dependency and regenerates aarch64-tune.md
if needed.
Tested on aarch64-linux and x86_64-linux (cross there), ok for trunk?
2022-04-04 Jakub Jelinek <jakub@redhat.com>
PR target/105144
* config/aarch64/t-aarch64 (s-mddeps): Depend on s-aarch64-tune-md.
* config/aarch64/aarch64-tune.md: Regenerated.
--- gcc/config/aarch64/t-aarch64.jj 2022-01-18 11:58:59.024990028 +0100
+++ gcc/config/aarch64/t-aarch64 2022-04-04 10:14:30.256323070 +0200
@@ -34,6 +34,8 @@ s-aarch64-tune-md: $(srcdir)/config/aarc
$(srcdir)/config/aarch64/aarch64-tune.md
$(STAMP) s-aarch64-tune-md
+s-mddeps: s-aarch64-tune-md
+
aarch64-builtins.o: $(srcdir)/config/aarch64/aarch64-builtins.cc $(CONFIG_H) \
$(SYSTEM_H) coretypes.h $(TM_H) \
$(RTL_H) $(TREE_H) expr.h $(TM_P_H) $(RECOG_H) langhooks.h \
--- gcc/config/aarch64/aarch64-tune.md.jj 2022-04-03 23:30:25.710798806 +0200
+++ gcc/config/aarch64/aarch64-tune.md 2022-04-04 10:14:55.668962478 +0200
@@ -1,5 +1,5 @@
;; -*- buffer-read-only: t -*-
;; Generated automatically by gentune.sh from aarch64-cores.def
(define_attr "tune"
- "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,ampere1,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa78,cortexa78ae,cortexa78c,cortexa65,cortexa65ae,cortexx1,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,a64fx,tsv110,thunderx3t110,zeus,neoversev1,neoverse512tvb,saphira,neoversen2,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55,cortexr82,cortexa510,cortexa710,cortexx2,demeter"
+ "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,ampere1,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa78,cortexa78ae,cortexa78c,cortexa65,cortexa65ae,cortexx1,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,a64fx,tsv110,thunderx3t110,zeus,neoversev1,neoverse512tvb,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55,cortexr82,cortexa510,cortexa710,cortexx2,neoversen2,demeter"
(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
Jakub
next reply other threads:[~2022-04-04 9:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 9:04 Jakub Jelinek [this message]
2022-04-04 10:05 ` Richard Sandiford
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=Ykq0sF7HVQnyTzp0@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=kyrylo.tkachov@arm.com \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.com \
/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).