[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gcc10's -Wreturn-local-addr gives FP warning about lib/careadlinkat

From: Pádraig Brady
Subject: Re: gcc10's -Wreturn-local-addr gives FP warning about lib/careadlinkat
Date: Fri, 7 Feb 2020 13:47:20 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Thunderbird/73.0

On 06/02/2020 17:05, Jim Meyering wrote:
On Thu, Feb 6, 2020 at 6:03 AM Pádraig Brady <address@hidden> wrote:
On 06/02/2020 00:27, Jim Meyering wrote:
Building latest latest coreutils using latest-from-git gcc10 evokes
this false positive:

lib/careadlinkat.c: In function 'careadlinkat':
cc1: error: function may return address of local variable
lib/careadlinkat.c:73:8: note: declared here
     73 |   char stack_buf[1024];

I'm guessing improved flow analysis will eventually suppress this. I
hesitate to turn off the useful and normally-high-S/N
-Wreturn-local-addr globally. Maybe just disable it in that one file,

The logic of the function looks fine.
Would an `assure (buf != stack_buf)` before the `return buf`
indicate that constraint to gcc with minimal runtime overhead?

I would have preferred that, but it has no effect.


I then tried to suppress that warning in the affected file by adding
these lines:

/* Without this pragma, gcc 10.0.1 20200205 reports that
    the "function may return address of local variable".  */
# pragma GCC diagnostic ignored "-Wreturn-local-addr"

But, surprisingly, that didn't help, either.

That suggests something major is up with that error
which might be easier for gcc folks to find.

Also tried Kaz Kylheku's return-early suggestion, to no avail.

Hence, my last resort suggestion: disable that warning option for all
gnulib compiles. Note that simply omitting the -W... option was
insufficient (probably pulled in by some high-level one), so I
resorted to adding -Wno-return-local-addr:


This is a significant enough regression that it should be reported.
I didn't see a gcc bug report, only this meta bug:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]