Hi! When a built-in function required by an overloaded function name is not currently enabled, the diagnostic message is not as clear as it should be. Saying that one built-in "requires" another is somewhat misleading. It is better to explicitly state that the overloaded builtin is implemented by the missing builtin, so the user knows that the previous error message for the implementing builtin is because of the overload relationship.
This patch adjusts the informational diagnostic for both the original support and the new builtin support. This doesn't affect the test suite, since we don't test for "note" diagnostics anywhere. Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this okay for trunk? Thanks! Bill 2021-11-23 Bill Schmidt <wschm...@linux.ibm.com> gcc/ * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Clarify diagnostic. (altivec_resolve_new_overloaded_builtin): Likewise. --- gcc/config/rs6000/rs6000-c.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c index d08bdfec3ae..5eeac9d4c06 100644 --- a/gcc/config/rs6000/rs6000-c.c +++ b/gcc/config/rs6000/rs6000-c.c @@ -1946,7 +1946,8 @@ altivec_resolve_overloaded_builtin (location_t loc, tree fndecl, non-overloaded function has already been issued. Add clarification of the previous message. */ rich_location richloc (line_table, input_location); - inform (&richloc, "builtin %qs requires builtin %qs", + inform (&richloc, + "overloaded builtin %qs is implemented by builtin %qs", name, internal_name); } else @@ -2992,7 +2993,8 @@ altivec_resolve_new_overloaded_builtin (location_t loc, tree fndecl, non-overloaded function has already been issued. Add clarification of the previous message. */ rich_location richloc (line_table, input_location); - inform (&richloc, "builtin %qs requires builtin %qs", + inform (&richloc, + "overloaded builtin %qs is implemented by builtin %qs", name, internal_name); } else -- 2.27.0