https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org,
| |rsandifo at gcc dot gnu.org
--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Hans-Peter Nilsson from comment #5)
> (In reply to Hans-Peter Nilsson from comment #4)
> > (In reply to Andrew Pinski from comment #1)
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627435.html
> >
> > Nope, that just fixes recog.h. See the quoted error; it's the patched
> > *-protos.h.
Thanks for clarifying, yeah, some ${port}-protos.h includes tree.h in that
commit.
>
> ...but I'm "guessing" that it will appear to work even for the
> tm-protos.h-on-tree.h dependency, just incidentally.
It can work for this build failure on build/gencondmd.o since the same required
dependency on tree.h is supported by checking the dependence of recog.h, but
the concern is that one day some file just includes tm_p.h but not recog.h, the
issue will show up again. I'm thinking how to deal with the problems on
${port}-protos.h, adding $(TREE_H) in TM_P is an alternative, but not sure if
people would think it's an overkill since the current affected ports are:
gcc/config/arm/arm-protos.h:#include "tree.h" /* For ERROR_MARK. */
gcc/config/cris/cris-protos.h:#include "tree.h" /* For ERROR_MARK. */
gcc/config/microblaze/microblaze-protos.h:#include "tree.h" /* For ERROR_MARK.
*/
gcc/config/rl78/rl78-protos.h:#include "tree.h" /* For ERROR_MARK. */
gcc/config/stormy16/stormy16-protos.h:#include "tree.h" /* For ERROR_MARK. */
I checked the existing tm_p_file_list and tm_p_include_list which are specific
for port, but tm_p_include_list is generated based on tm_p_file_list, it seems
not for this purpose.
Hi Richi & Richard, what do you think of this?
btw, thanks for the suggestion on "defaulting to NULL or something" in ML, but
I guess a default value like zero rather than ERROR_MARK has to base on the
assertion that the default value is equal to ERROR_MARK, IMHO it isn't quite
maintainable.
