Bug 95044 - [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1ffd037
Summary: [10/11 Regression] -Wreturn-local-addr false alarm since r10-1741-gaac9480da1...
Status: RESOLVED DUPLICATE of bug 93644
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 10.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wreturn-local-addr
  Show dependency treegraph
 
Reported: 2020-05-10 23:56 UTC by eggert
Modified: 2020-05-11 14:28 UTC (History)
3 users (show)

See Also:
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


Attachments
Illustrate the -Wreturn-local-addr bug. (256 bytes, text/plain)
2020-05-10 23:56 UTC, eggert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description 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 ***