https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #10 from Kewen Lin <linkw at gcc dot gnu.org> --- (In reply to Hans-Peter Nilsson from comment #7) > Exactly; I'm happy that we seem to be on the same page here. > > I'm testing a patch for CRIS (making the hook function just a wrapper, > reverting the cris-protos.h change) that may be re-usable for the other > targets similarly affected. > https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627444.html Thanks for the suggestion and doing the patch! If Richi & Richard prefer this, I'll follow up with a patch for the other affected ports. > I believe you could add a code_helper constructor for another type, maybe > even "int"? Then the "default" value for the code_helper argument for the > legitimate address hook function would just look like "code_helper = 0". > > Maybe that's too error-prone and a pointer-type or some entirely different > type would be better. I might have misunderstood things of course, but > that's what I mean by "or something". OK, thanks for further clarifying, I agree it's doable, I didn't consider this before because it's a "code" helper, as its comments says it's for tree codes and builtin function codes, shouldn't make it support things that isn't "code". Even for a int which can be equivalent to a tree_code (with an appropriate assertion check for unexpected range), it's still easy to be questioned like why not just use tree_code directly (having good readability and without any expected range checking etc.).
