[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
I didn't know that GCC considers attribute warn_unused_result part of the
function type.  When you say that most of these attributes apply to the
function type, which others are you referring to?

FWIW, I find this surprising not only because the attribute is documented as a
function attribute and not one that applies to types, but also because it's
different from other common function attributes that affect warnings such as
attribute unused or used.  Those are not considered to be part of the function
type as the test case below shows.

$ cat x.C && /home/msebor/build/gcc-trunk-svn/gcc/xgcc -B
/home/msebor/build/gcc-trunk-svn/gcc -O2 -S -Wall -Wextra -Wpedantic -xc++ x.C
static void __attribute ((unused)) f_unused (void);
static void f_unused (void) { }   // no warning as expected

static void __attribute ((used)) f_used (void);
static void f_used (void) { }   // no warning as expected

static __typeof__ (f_unused) g_unused;
static void g_unused (void) { }   // emits -Wnunused-function

static __typeof__ (f_used) g_used;
static void g_used (void) { }   // emits -Wnunused-function
x.C:11:13: warning: ‘void g_used()’ defined but not used [-Wunused-function]
 static void g_used (void) { }   // emits -Wnunused-function
             ^~~~~~
x.C:8:13: warning: ‘void g_unused()’ defined but not used [-Wunused-function]
 static void g_unused (void) { }   // emits -Wnunused-function
             ^~~~~~~~

I also tried a few other others, including attribute weak and attribute
nothrow, but couldn't find one where the attribute is treated as part of the
function type.

In any case, if warn_unused_result is meant to be part of the function type
then the right resolution is to update the documentation to make it clear.  I'm
willing to put together a documentation patch if you're convinced that's the
right fix though it seems to me that changing GCC to have the attribute behave
like the others above would be preferable.