public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] aarch64: Fix aarch64-tune.md (re)generation [PR105144]
@ 2022-04-04  9:04 Jakub Jelinek
  2022-04-04 10:05 ` Richard Sandiford
  0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2022-04-04  9:04 UTC (permalink / raw)
  To: Richard Earnshaw, Richard Sandiford, Kyrylo Tkachov; +Cc: gcc-patches

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] aarch64: Fix aarch64-tune.md (re)generation [PR105144]
  2022-04-04  9:04 [PATCH] aarch64: Fix aarch64-tune.md (re)generation [PR105144] Jakub Jelinek
@ 2022-04-04 10:05 ` Richard Sandiford
  0 siblings, 0 replies; 2+ messages in thread
From: Richard Sandiford @ 2022-04-04 10:05 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Richard Earnshaw, Kyrylo Tkachov, gcc-patches

Jakub Jelinek <jakub@redhat.com> writes:
> 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.

OK, thanks.

Richard

>
> --- 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-04-04 10:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-04  9:04 [PATCH] aarch64: Fix aarch64-tune.md (re)generation [PR105144] Jakub Jelinek
2022-04-04 10:05 ` Richard Sandiford

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).