On Fri, 5 May 2023, Alexander Monakov wrote: > > > gimple-head-export.cc does not exist. > > > > > > gimple-match-exports.cc is not a generated file. It's under source > > > control and > > > edited independently from genmatch.cc. It is compiled separately, > > > producing > > > gimple-match-exports.o. > > > > > > gimple-match-head.cc is also not a generated file, also under source > > > control. > > > It is transitively included into gimple-match-N.o files. If it changes, > > > they will be > > > rebuilt. This is not changed by my patch. > > > > > > gimple-match-auto.h is a generated file. It depends on s-gimple-match > > > stamp > > > file, which in turn depends on genmatch and match.pd. If either changes, > > > the > > > rule for the stamp file triggers. gimple-match-N.o files also depend on > > > the > > > stamp file, so they will be rebuilt as well. > > > > s-gimple-match does not depend on gimple-match-head.cc. if it changes the > > stamp > > is not invalidated. > > Right, this is correct: there's no need to rerun the recipe for the stamp, > because contents of gimple-match-head.cc do not affect it. > > > This happens to work because gimple-match-N.cc does depend on > > gimple-match-head.cc, > > but if the gimple-match-N.cc already exists then nothing changes. > > No, if gimple-match-N.cc already exist, make notices they are out-of-date via > > $(GIMPLE_MATCH_PD_SEQ_SRC): s-gimple-match gimple-match-head.cc; @true > > and this triggers rebuilding gimple-match-N.o. > > I tested this. After 'touch gimple-match-head.cc' all ten gimple-match-N.o > files > are rebuilt.
My explanation was incomplete here. The gcc/Makefile.in rule quoted above applies to .cc files and does not trigger rebuilds of .o files on its own. The reason .o files get rebuilt is implicit dependency tracking: initial build records header dependencies in gcc/.deps/*.Po files, and incremental rebuild sees that gimple-match-1.o depends on gimple-match-head.cc. Alexander
