[Bug target/105144] New: [12 Regression] Bootstrap + install failure on aarch64 due to aarch64-tune.md likely since r12-7842

[jakub at gcc dot gnu.org]

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

            Bug ID: 105144
           Summary: [12 Regression] Bootstrap + install failure on aarch64
                    due to aarch64-tune.md likely since r12-7842
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Latest Fedora package builds fail on aarch64, I believe it is caused by
r12-7842-g9f37d31324f89d0b7b2abac988a976d121ae29c6 (but haven't actually
bisected).  See e.g.
https://kojipkgs.fedoraproject.org//work/tasks/8070/85048070/build.log

We are doing a --with-build-config=bootstrap-lto --enable-link-serialization=1
profiledbootstrap with system gcc less than 4 weeks old gcc trunk snapshot.
What I see in the log is that it bootstraps just fine, then during make install
does:
/bin/sh ../../gcc/config/aarch64/gentune.sh \
        ../../gcc/config/aarch64/aarch64-cores.def > \
        tmp-aarch64-tune.md
/bin/sh ../../gcc/../move-if-change tmp-aarch64-tune.md \
        ../../gcc/config/aarch64/aarch64-tune.md
echo timestamp > s-aarch64-tune-md
which hasn't been done during the bootstrap time, this changes aarch64-tune.md
and so it rebuilds quite a few but not all *.o files but with the system g++
rather than the new compiler and ICEs on lto1 because there were silent changes
in the LTO bytecode between compiler from ~ 4 weeks ago and current one.
There are multiple issues related to this:
1) the r12-7842 change changed aarch64-cores.def (moved neoverse-n2 entry
later)
   but didn't regenerate and commit aarch64-tune.md
2) the reason why gentune.sh isn't invoked during bootstrap but is during
   install is I believe caused by:
# Dependencies for the md file.  The first time through, we just assume
# the md file itself and the generated dependency file (in order to get
# it built).  The second time through we have the dependency file.
-include mddeps.mk
MD_DEPS = s-mddeps $(md_file) $(MD_INCLUDES)

s-mddeps: $(md_file) $(MD_INCLUDES) build/genmddeps$(build_exeext)
        $(RUN_GEN) build/genmddeps$(build_exeext) $(md_file) > tmp-mddeps
        $(SHELL) $(srcdir)/../move-if-change tmp-mddeps mddeps.mk
        $(STAMP) s-mddeps
   When bootstrapping gcc into a fresh new object directory (well, set of them,
   like stage{1,2,3}-gcc, stageprofile-gcc, prev-gcc, gcc etc.),
   mddeps.mk doesn't
   exist and so isn't included and everything that depends on the *.md file(s)
   depends just on s-mddeps that creates the mddeps.mk, on the main $(md_file)
   (gcc/config/aarch64/aarch64.md in this case) and that is it.  Not a big deal
   the first time, as everything is being rebuild.  But for aarch64 it means
   that gentune.sh which is from:
$(srcdir)/config/aarch64/aarch64-tune.md: s-aarch64-tune-md; @true
s-aarch64-tune-md: $(srcdir)/config/aarch64/gentune.sh \
        $(srcdir)/config/aarch64/aarch64-cores.def
        $(SHELL) $(srcdir)/config/aarch64/gentune.sh \
                $(srcdir)/config/aarch64/aarch64-cores.def > \
                tmp-aarch64-tune.md
        $(SHELL) $(srcdir)/../move-if-change tmp-aarch64-tune.md \
                $(srcdir)/config/aarch64/aarch64-tune.md
        $(STAMP) s-aarch64-tune-md
   isn't invoked at that point.  Next during make install, mddeps.mk already
   exists and so it invokes it, regenerates it and as it is different,
   move-if-change overwrites it
3) I think it is wrong to change files in $(srcdir) or its subdirs during
   build except for --enable-maintainer-mode, users could have the tree
   in read-only location etc.