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.
