On Thu, Aug 8, 2024 at 4:55 AM Peter Damianov <peter0...@disroot.org> wrote:
>
> Currently, if a warning references a cloned function, the name of the cloned
> function will be emitted in the "In function 'xyz'" part of the diagnostic,
> which users aren't supposed to see. This patch follows the DECL_ORIGIN link
> to get the name of the original function, so the internal compiler details
> aren't exposed.
Note I see an almost exact copy of the function in cp/error.cc as
cp_print_error_function (possibly more modern), specifically using
pp_printf (context->printer, function_category (fndecl),
fndecl);
which ends up using %qD.
I've CCed David who likely invented diagnostic_abstract_origin and friends.
> gcc/ChangeLog:
> PR diagnostics/102061
> * langhooks.cc (lhd_print_error_function): Follow DECL_ORIGIN
> links.
> * gcc.dg/pr102061.c: New testcase.
>
> Signed-off-by: Peter Damianov <peter0...@disroot.org>
> ---
> v3: also follow DECL_ORIGIN when emitting "inlined from" warnings, I missed
> this before.
> Add testcase.
>
> gcc/langhooks.cc | 3 +++
> gcc/testsuite/gcc.dg/pr102061.c | 35 +++++++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+)
> create mode 100644 gcc/testsuite/gcc.dg/pr102061.c
>
> diff --git a/gcc/langhooks.cc b/gcc/langhooks.cc
> index 61f2b676256..7a2a66b3c39 100644
> --- a/gcc/langhooks.cc
> +++ b/gcc/langhooks.cc
> @@ -395,6 +395,8 @@ lhd_print_error_function (diagnostic_context *context,
> const char *file,
> else
> fndecl = current_function_decl;
>
> + fndecl = DECL_ORIGIN(fndecl);
Space after DECL_ORIGIN. There's a comment warranted for what we
intend do to here.
I think this change is reasonable.
> +
> if (TREE_CODE (TREE_TYPE (fndecl)) == METHOD_TYPE)
> pp_printf
> (context->printer, _("In member function %qs"),
> @@ -439,6 +441,7 @@ lhd_print_error_function (diagnostic_context *context,
> const char *file,
> }
> if (fndecl)
> {
> + fndecl = DECL_ORIGIN(fndecl);
Space missing again.
This change OTOH might cause us to print
inlined from foo at ...
inlined from foo at ...
so duplicating an inline for example in the case we split a function and then
inline both parts or in the case we inline a IPA-CP forwarder and the specific
clone. It's not obvious what we should do here since of course for a recursive
function we can have a function inlined two times in a row.
The testcase only triggers the first case, right?
David, any comments? I think the patch is OK with the formatting fixed.
Thanks,
Richard.
> expanded_location s = expand_location (*locus);
> pp_comma (context->printer);
> pp_newline (context->printer);
> diff --git a/gcc/testsuite/gcc.dg/pr102061.c b/gcc/testsuite/gcc.dg/pr102061.c
> new file mode 100644
> index 00000000000..dbdd23965e7
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr102061.c
> @@ -0,0 +1,35 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Wall -O2" } */
> +/* { dg-message "inlined from 'bar'" "" { target *-*-* } 0 } */
> +/* { dg-excess-errors "" } */
> +
> +static inline void
> +foo (char *p)
> +{
> + __builtin___memcpy_chk (p, "abc", 3, __builtin_object_size (p, 0));
> +}
> +static void
> +bar (char *p) __attribute__((noinline));
> +static void
> +bar (char *p)
> +{
> + foo (p);
> +}
> +void f(char*) __attribute__((noipa));
> +char buf[2];
> +void
> +baz (void) __attribute__((noinline));
> +void
> +baz (void)
> +{
> + bar (buf);
> + f(buf);
> +}
> +
> +void f(char*)
> +{}
> +
> +int main(void)
> +{
> + baz();
> +}
> --
> 2.39.2
>
