https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #17 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to Richard Biener from comment #12) > I think a "too broad" dependence isn't bad. The cris specific solution also > looks manageable, though I wonder what's special about x-protos.h, knowing > very little of that area. Not very special, it's just that there's a now dependence on tree.h and its generated contents where for tm-protos.h there has been none before. The reasons seem avoidable at this time, but I think it's nominally valid to have that dependency. On the one hand, introducing a new dependency where there has been none before and dealing with the fallout we now see is awkward, but on the other hand pragmatically the dependence on tree.h for $(TM_P) is trivial enough that a parallel build "raced" to fulfill it. IOW, shouldn't affect build time by any measure. (Not closing this PR yet in case maintainers go forward for the other tm-protos.h-affected targets)
