[Bug c/63943] New: -Wmaybe-uninitialized pragma mishandled in inlined function

[Bug c/63943] New: -Wmaybe-uninitialized pragma mishandled in inlined function

[eggert at gnu dot org]

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

            Bug ID: 63943
           Summary: -Wmaybe-uninitialized pragma mishandled in inlined
                    function
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eggert at gnu dot org

Created attachment 34031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34031&action=edit
Program with -Wmaybe-uninitialized problem

Compile the attached program t.c with "gcc -Wmaybe-uninitialized -O2 -c t.c" on
x86-64 with GCC 4.9.2, and the output will be:

t.c: In function 'main':
t.c:17:3: warning: '*((void *)&v+4)' may be used uninitialized in this function
[-Wmaybe-uninitialized]
   return argc < 1 ? !argv : dereference (v + 1);
   ^

'#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"' is in effect when the
possibly-uninitialized variable is used, but this use is in a function that GCC
inlined, and GCC is incorrectly warning based on the pragma setting in the
calling function, not based on the pragma setting where the dereferencing
actually occurs.

The problem does not occur with GCC 4.8.3 so this appears to be a regression.

The problem also goes away if I add '__attribute__((noinline))' to the
'dereference' function, so this appears to be related to inlining.

I ran into this problem while thinking about enabling -Werror when compiling
glibc; my first cut at this ran into the above problem.

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-19
                 CC|                            |manu at gcc dot gnu.org
             Blocks|                            |24639
            Summary|-Wmaybe-uninitialized       |wrong location for
                   |pragma mishandled in        |-Wmaybe-uninitialized in
                   |inlined function            |inlined function
     Ever confirmed|0                           |1
      Known to fail|                            |4.9.2, 5.0

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Confirmed also in GCC 5.0.

The problem is the location info that is available in the middle-end and how
this is transformed when inlining and renaming/propagating copies. To be able
to silence this, the warning should be given at the location of 'return *p'. 

We have the correct location in 028t.esra:
;;   basic block 4, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 3, next block 5, flags: (NEW, REACHABLE)
;;    pred:       2 (FALSE_VALUE,EXECUTABLE)
;;   starting at line 7
  [test.c:7:10] _9 = v$4_14(D);
  _13 = _9;
  [test.c:17:27] iftmp.0_10 = _9;
;;    succ:       5 (FALLTHRU,EXECUTABLE)

but the middle-end loses it after 030t.fre1:

;;   basic block 5, loop depth 0, count 0, freq 0, maybe hot
;;    prev block 4, next block 1, flags: (NEW, REACHABLE)
;;    pred:       3 (FALLTHRU,EXECUTABLE)
;;                4 (FALLTHRU,EXECUTABLE)
;;   starting at line -1, discriminator 4
  # iftmp.0_1 = PHI <[test.c:17:27] iftmp.0_8(3), [test.c:17:27] v$4_14(D)(4)>


As a side note, I wonder if %K could be used here to get an "inline-from"
backtrace like we do in other diagnostics.
>From gcc-bugs-return-467515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 19 15:23:38 2014
Return-Path: <gcc-bugs-return-467515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22080 invoked by alias); 19 Nov 2014 15:23:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22030 invoked by uid 48); 19 Nov 2014 15:23:34 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/36312] should refuse to overwrite input file with output file
Date: Wed, 19 Nov 2014 15:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: 4.1.2
X-Bugzilla-Keywords: diagnostic, patch
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-36312-4-oj3m4jNZDQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36312-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36312-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg01987.txt.bz2
Content-length: 760

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

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to carlos from comment #15)
> It would be sufficient if /dev/null were special cased in some way for Linux
> configurations.

There is a pre-approved patch here
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837#c12) that I'm testing.
Unfortunately, there seems to be a problem with the machine in the compile farm
that I use for gcc development, and I'm not able to finish a
bootstrap&regression test. I always get:

couldn't create output pipe for command: too many open files

even for a pristine copy of GCC. This didn't happen a few days ago. I didn't
have time yet to investigate what is wrong.
>From gcc-bugs-return-467516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 19 15:24:11 2014
Return-Path: <gcc-bugs-return-467516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22846 invoked by alias); 19 Nov 2014 15:24:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22811 invoked by uid 48); 19 Nov 2014 15:24:07 -0000
From: "tbsaunde at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/50687] Missing symbols with -flto -fvisibility=hidden on 4.6.x but not on 4.7.0
Date: Wed, 19 Nov 2014 15:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.6.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tbsaunde at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-50687-4-W5O1RrT2XM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50687-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50687-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg01988.txt.bz2
Content-length: 565

https://gcc.gnu.org/bugzilla/show_bug.cgi?idP687

tbsaunde at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |tbsaunde at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #5 from tbsaunde at gcc dot gnu.org ---
both 4.6 and 4.7 are unmaintained at this point, and this seems like reasonable
behavior anyway.

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
   Last reconfirmed|2014-11-19 00:00:00         |2021-3-31
      Known to fail|4.9.2, 5.0                  |10.2.0, 11.0, 4.9.4, 5.5.0,
                   |                            |6.4.0, 7.2.0, 8.3.0, 9.1.0

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
Reconfirmed with GCC 11 with mostly the same observations as in comment #1.

As for using %K, I mostly agree.  I actually have %G in my tree, but my goal is
to get rid of both and replace them with a new warning function like so:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
and replace calls to warning() and warning_at() in the middle end with those to
the new function.  This makes it possible to control warnings at any point in
the lining stack and resolves bug like pr98871.

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #3)
> As for using %K, I mostly agree.  I actually have %G in my tree, but my goal
> is to get rid of both and replace them with a new warning function like so:
>   https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
> and replace calls to warning() and warning_at() in the middle end with those
> to the new function.  This makes it possible to control warnings at any
> point in the lining stack and resolves bug like pr98871.

That is great. It may be worth CCing David Malcolm, since he is the diagnostics
maintainer. A couple of comments:

* #include "tree.h" in diagnostic.c is not great. Ideally, diagnostic.c should
be independent of trees so that other front-ends can use it without having to
use tree. We went through a lot of work to make the core diagnostics
independent of any FE or Middle-end and only depend on line-map and options
handling. The original plan is to move it to its own library/module, but I
guess there has been little progress in the modular GCC.

* There is a tree-diagnostic.c. Everything that depends on tree.h should be
moved there. (again, if there was a modular GCC, this would be obvious but
alas...)

* Although it is more work, I think Richard and other middle-end reviewers
would be more motivated to accept this if it removed completely
percent_K_format. That is, rather than add yet-another-way, completely replaces
the old %K with something better.

* I don't contribute to GCC anymore, but rather than doing:

diag_inlining_context dic (exp);
warning (dic, opt, "%qD specified size %E may exceed maximum object size %E",
        func, bndrng[0], maxobjsize);

I'd prefer:

warning_at_inlined_context(exp, opt, "%qD specified size %E may exceed maximum
object size %E", func, bndrng[0], maxobjsize);

This way, I don't need to know about class diag_inlining_context nor about
another variable (dic). I just need to know about an alternative warning
function and the magic is hidden from me. This function can live in
tree-diagnostic.c which contains the tree-specific functions for diagnostics.

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmalcolm at gcc dot gnu.org,
                   |                            |egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Martin Sebor from comment #3)
> > As for using %K, I mostly agree.  I actually have %G in my tree, but my goal
> > is to get rid of both and replace them with a new warning function like so:
> >   https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
> > and replace calls to warning() and warning_at() in the middle end with those
> > to the new function.  This makes it possible to control warnings at any
> > point in the lining stack and resolves bug like pr98871.
> 
> That is great. It may be worth CCing David Malcolm, since he is the
> diagnostics maintainer.

OK, done

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://gcc.gnu.org/bugzill |
                   |a/show_bug.cgi?id=81962     |
                 CC|                            |janus at gcc dot gnu.org

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 81962 has been marked as a duplicate of this bug. ***