Bug 44321 - attribute warn_unused_result fails under inlining.
Summary: attribute warn_unused_result fails under inlining.
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2010-05-29 11:32 UTC by Dave Korn
Modified: 2014-03-07 21:45 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
testcase as per initial comment. (134 bytes, text/plain)
2010-05-29 11:33 UTC, Dave Korn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Korn 2010-05-29 11:32:54 UTC
In the (to-be) attached testcase, GCC warns about an unused result when the return value of the function is ignored, or cast to void, but it fails to warn when the cast-to-void is hidden inside an inline function, like so:

$ cat -n wur.c
     1
     2  static inline void ignore_value (int i) { (void) i; }
     3
     4  extern int foo (void) __attribute__ ((warn_unused_result));
     5
     6  void bar1 (void)
     7  {
     8    foo ();
     9  }
    10
    11  void bar2 (void)
    12  {
    13    (void) foo ();
    14  }
    15
    16  void bar3 (void)
    17  {
    18    ignore_value (foo ());
    19  }

$ gcc-4 -c wur.c  -o wur.o --save-temps -W -Wall -Wextra
wur.c: In function 'bar2':
wur.c:13:3: warning: ignoring return value of 'foo', declared with attribute war
n_unused_result [-Wunused-result]
wur.c: In function 'bar1':
wur.c:8:7: warning: ignoring return value of 'foo', declared with attribute warn
_unused_result [-Wunused-result]

This happens at all -O levels.  I haven't filled in the host/target/build triplets because I don't suppose it is in any way specific to any of them.

BTW, it's interesting that the warnings come out in reverse order, is that supposed to happen?
Comment 1 Dave Korn 2010-05-29 11:33:30 UTC
Created attachment 20771 [details]
testcase as per initial comment.
Comment 2 Richard Biener 2010-05-29 11:40:17 UTC
You can add

void bar4 (void)
{
  int dummy;
  dummy = foo ();
}

so I'm not sure the ignore_value () function call isn't a use.  In fact
if you externalize that function it is at least a possible use.

Which also raises the question whether (void) is really more "ignoring"
the result than the assignment to a dummy variable.
Comment 3 Paolo Bonzini 2010-05-29 17:32:26 UTC
I don't think this bug is of any use.  Unlike nonnull, unused return values do not trigger undesirable optimizations and (as far as I can tell) cannot possibly result in miscompilation.

This bug is indeed about a loophole, and one that could indeed cause some bugs (even security bugs).  But, fixing it would also make it impossible for many projects to use -Werror, since they have to deal with the fact that __wur was used inappropriately by glibc.

Adding another attribute and making __wur overridable BTW would not be a solution since glibc would certainly switch to the new __really_wur attribute and we'd be in the same situation.  :-)
Comment 4 Richard Biener 2010-05-29 17:46:08 UTC
(In reply to comment #3)
> I don't think this bug is of any use.  Unlike nonnull, unused return values do
> not trigger undesirable optimizations and (as far as I can tell) cannot
> possibly result in miscompilation.
> 
> This bug is indeed about a loophole, and one that could indeed cause some bugs
> (even security bugs).  But, fixing it would also make it impossible for many
> projects to use -Werror, since they have to deal with the fact that __wur was
> used inappropriately by glibc.
> 
> Adding another attribute and making __wur overridable BTW would not be a
> solution since glibc would certainly switch to the new __really_wur attribute
> and we'd be in the same situation.  :-)

True, but if int dummy = foo() works then we can also make (void) foo ()
work.
Comment 5 Paolo Bonzini 2010-05-30 06:42:57 UTC
Richi, I think we're saying the same thing from two different directions.