Bug 95044

Summary: [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1ffd037
Product: gcc Reporter: Paul Eggert <eggert>
Component: cAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: egallager, marxin, msebor
Priority: P3 Keywords: diagnostic
Version: 10.1.0   
Target Milestone: ---   
See Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
Host: Target:
Build: Known to work: 9.3.0
Known to fail: 10.1.0, 11.0 Last reconfirmed: 2020-05-11 00:00:00
Bug Depends on:    
Bug Blocks: 90556    
Attachments: Illustrate the -Wreturn-local-addr bug.

Description Paul Eggert 2020-05-10 23:56:00 UTC
Created attachment 48501 [details]
Illustrate the -Wreturn-local-addr bug.

I ran into this problem when compiling GNU Emacs master with GCC 10.1.0 x86-64, which I built from source on RHEL 7.7.

Compile the attached program u.c with:

gcc -S -Wreturn-local-addr -O2 u.c

The output is:

u.c: In function 'careadlinkat':
cc1: warning: function may return address of local variable [-Wreturn-local-add\
r]
u.c:7:8: note: declared here
    7 |   char stack_buf[1024];
      |        ^~~~~~~~~


It's obviously impossible for the function to return that address. This false alarm is not generated by GCC 9.3.0, so this is a regression.

There are really two bugs here:

1. GCC is ignoring the '#pragma GCC diagnostic ignored "-Wreturn-local-addr"' and is outputting the diagnostic anyway.

2. GCC should not issue a diagnostic even if the pragma is absent, as it's obviously impossible for the function to return the address of stack_buf.

Both bugs are new to GCC 10.1.0; they do not occur with GCC 9.3.0.
Comment 1 Marc Glisse 2020-05-11 10:05:09 UTC
I think there is another very similar bug report.

  # buf_1 = PHI <&stack_buf(2), buf_15(6)>
[...]
  if (&stack_buf != buf_1)

in each branch, we thus know what buf_1 is, so we could replace it with buf_15 in

  # _3 = PHI <_17(5), buf_1(4)>
  return _3;

(or is that bad for register pressure?)

Or use it as a hint to thread that path, or add some logic to Wreturn_local_addr, but that's getting more complicated.
Comment 2 Andrew Pinski 2020-05-11 10:15:56 UTC
Peeling off the first iteration might be the answer.  Thread jumping could do that but normally is not used for that, especially through other condtionals.
Comment 3 Martin Sebor 2020-05-11 14:28:01 UTC
This looks like a duplicate of pr93644, including the test case involving the careadlinkat function.

*** This bug has been marked as a duplicate of bug 93644 ***