[Bug middle-end/109559] New: Unexpected -Wmaybe-uninitialized warning when inlining with system header

[Bug middle-end/109559] New: Unexpected -Wmaybe-uninitialized warning when inlining with system header

[mpolacek at gcc dot gnu.org]

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

            Bug ID: 109559
           Summary: Unexpected -Wmaybe-uninitialized warning when inlining
                    with system header
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following testcase (the directives simulate a system header) triggers a
-Wmaybe-uninitialized warning:

$ xg++ -c un.cc -Wall -O2
In member function ‘int function1::swap(function1)’,
    inlined from ‘int function::operator=(Functor) [with Functor =
FilonIntegral::integrate() const::<lambda()>]’ at :8:56,
    inlined from ‘double FilonIntegral::integrate() const’ at :9:6:
:5:49: warning: ‘f1’ may be used uninitialized [-Wmaybe-uninitialized]
: In member function ‘double FilonIntegral::integrate() const’:
:1:3: note: by argument 1 of type ‘const function_base*’ to ‘int
function_base::has_trivial_copy_and_destroy() const’ declared here
:8:12: note: ‘f1’ declared here

$ xg++ -c un.cc -Wall -O2 -fno-inline
# nothing

# 0 "" 3
struct function_base {
  has_trivial_copy_and_destroy() const;
  int functor;
};
struct function1 : function_base {
  swap(function1) { has_trivial_copy_and_destroy(); }
};
struct function : function1 {
  template <typename Functor> operator=(Functor) { swap(*this); }
};
# 4 ""
struct FilonIntegral {
  double integrate() const;
};
double FilonIntegral::integrate() const {
  function f1;
  f1 = [] {};
  return 0;
}

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Unexpected                  |[12/13/14 Regression]
                   |-Wmaybe-uninitialized       |Unexpected
                   |warning when inlining with  |-Wmaybe-uninitialized
                   |system header               |warning when inlining with
                   |                            |system header
           Keywords|                            |diagnostic
   Target Milestone|---                         |12.3

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Started with r12-1992.  

We have an inlining context containing locations for each call site along
the inlining stack: struct inlining_info.  It has a stack of locations,
and a flag that says whether all of them come from a system header.  If so,
we don't warn:

1548   if (!report_warning_p && diagnostic->m_iinfo.m_allsyslocs)
1549     /* Bail if the warning is not to be reported because all locations
1550        in the inlining stack (if there is one) are in system headers.  */
1551     return false;

but in this test diagnostic->m_iinfo.m_allsyslocs is false because the inlining
causes that the outermost context is the un.cc file, which is not a system
header.

It looks like this is a failure to propagate the sysp flag when inlining a
function.

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Originally this happened when including boost headers, function_template.hpp in
particular, where newer versions suppress a lot of warnings:

commit b75386f628b46f1060a20b6e015931bac37b7da7 (origin/feature/drone)
Author: Peter Dimov <pdimov@gmail.com>
Date:   Sun Feb 12 04:50:04 2023 +0200

    Avoid -Wuninitialized under GCC 11.3

commit 9229ed30103df59a4f989ca0235b0d1026bf6e1c
Author: Peter Dimov <pdimov@gmail.com>
Date:   Sun Feb 12 04:47:38 2023 +0200

    Avoid another -Wmaybe-uninitialized under GCC 11/12

commit 16fca8368b5da14c4bcad977c2738dc6e482e1b7 (tag: boost-1.81.0.beta1, tag:
boost-1.81.0, tag: boost-1.80.0.beta1, tag: boost-1.80.0,
origin/feature/issue-42)
Author: Peter Dimov <pdimov@gmail.com>
Date:   Mon May 30 20:25:13 2022 +0300

    Keep -Wmaybe-uninitialized disabled

commit 4cf7c718b873223cbab6f8188bea2034f27ba99d
Merge: 389f886 5b4e279
Author: Peter Dimov <pdimov@gmail.com>
Date:   Mon May 30 19:56:08 2022 +0300

    Merge branch 'gcc12-Wuninitialized' of
https://github.com/jngrad/boost-function into feature/issue-42

commit abc1bf9b4ae3f45251d17b451c69c3e79dfd0cf6 (origin/feature/update-ci)
Author: Peter Dimov <pdimov@gmail.com>
Date:   Mon May 30 18:44:07 2022 +0300

    Extend GCC 11 workaround to GCC 12 as well

commit 5b4e2797a28f9477d2df5fa915409dac73ff00c6
Author: Jean-Noël Grad <jgrad@icp.uni-stuttgart.de>
Date:   Mon May 30 16:16:41 2022 +0200

    Avoid -Wuninitialized warnings in GCC 12

commit 277757befc321bda3b9d8038ee59ae6e4616cdca
Author: Peter Dimov <pdimov@gmail.com>
Date:   Thu Dec 16 06:18:06 2021 +0200

    Disable -Wmaybe-uninitialized in function_template.hpp for GCC 11

commit 7c90434317894f1a0c63c7a395ddf569eff1d308
Author: Romain Geissler <romain.geissler@amadeus.com>
Date:   Fri Mar 27 18:56:14 2020 +0000

    Avoid -Wmaybe-uninitialized warnings in gcc (issue #27).

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.3                        |12.4

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2024-01-12

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
That

'# nothing'

is rejected with

t.ii:1:3: error: invalid preprocessing directive #nothing
    1 | # nothing
      |   ^~~~~~~

for me.  I can't reproduce this thus.

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Sorry, that wasn't part of the test.

```
# 0 "" 3
struct function_base {
  has_trivial_copy_and_destroy() const;
  int functor;
};
struct function1 : function_base {
  swap(function1) { has_trivial_copy_and_destroy(); }
};
struct function : function1 {
  template <typename Functor> operator=(Functor) { swap(*this); }
};
# 4 ""
struct FilonIntegral {
  double integrate() const;
};
double FilonIntegral::integrate() const {
  function f1;
  f1 = [] {};
  return 0;
}
```

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |msebor at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note the diagnostic is "valid" and for

FilonIntegral::integrate ()

<bb2:>
function_base::has_trivial_copy_and_destroy (&MEM[(struct function1
*)&f1].D.2804);

and we're using the stmts location to diagnose this which expands to

(gdb) p IS_ADHOC_LOC (location)
$8 = true
(gdb) p get_location_from_adhoc_loc (line_table, location)
$9 = 268224
(gdb) p expand_location ($9)
$10 = {file = 0x4d895d0 "", line = 5, column = 49, data = 0x0, sysp = true}

so the system header flag is correct.  There's

  if ((was_warning || diagnostic->kind == DK_WARNING)
      && ((!m_warn_system_headers
           && diagnostic->m_iinfo.m_allsyslocs)
          || m_inhibit_warnings))
    /* Bail if the warning is not to be reported because all locations in the
       inlining stack (if there is one) are in system headers.  */
    return false; 

I've added -Wno-system-headers, and

(gdb) p m_warn_system_headers
$14 = false
(gdb) p diagnostic->m_iinfo.m_allsyslocs
$15 = false
(gdb) p was_warning
$16 = true
(gdb) p m_inhibit_warnings
$17 = false

so the issue seems to be that the active m_set_locations_cb
tree-diagnostic.cc:set_inlining_locations computes that "wrongly".

The operator= associated inline block location isn't in a system header
(the abstract origin, the operator= FUNCTION_DECL does have a
DECL_SOURCE_LOCATION that's in a system header though).

_Note_ we're assigning that BLOCK the location of the _call_ (it's for
the parameter setup), _not_ the location of the callee!

  /* Build a block containing code to initialize the arguments, the
     actual inline expansion of the body, and a label for the return
     statements within the function to jump to.  The type of the
     statement expression is the return type of the function call.
     ???  If the call does not have an associated block then we will
     remap all callee blocks to NULL, effectively dropping most of
     its debug information.  This should only happen for calls to
     artificial decls inserted by the compiler itself.  We need to
     either link the inlined blocks into the caller block tree or
     not refer to them in any way to not break GC for locations.  */
  if (tree block = gimple_block (stmt))
    {
      /* We do want to assign a not UNKNOWN_LOCATION BLOCK_SOURCE_LOCATION
         to make inlined_function_outer_scope_p return true on this BLOCK.  */
      location_t loc = LOCATION_LOCUS (gimple_location (stmt));
      if (loc == UNKNOWN_LOCATION)
        loc = LOCATION_LOCUS (DECL_SOURCE_LOCATION (fn));
      if (loc == UNKNOWN_LOCATION)
        loc = BUILTINS_LOCATION;
      id->block = make_node (BLOCK);
      BLOCK_ABSTRACT_ORIGIN (id->block) = DECL_ORIGIN (fn);
      BLOCK_SOURCE_LOCATION (id->block) = loc;
      prepend_lexical_block (block, id->block);

since this particular hook implementation was added by Martin S. I don't
have high hopes of that being a concious decision.

  while (block && TREE_CODE (block) == BLOCK
         && BLOCK_ABSTRACT_ORIGIN (block))
    {
      tree ao = BLOCK_ABSTRACT_ORIGIN (block);
      if (TREE_CODE (ao) == FUNCTION_DECL)
        {
          if (!diagnostic->m_iinfo.m_ao)
            diagnostic->m_iinfo.m_ao = block;

          location_t bsloc = BLOCK_SOURCE_LOCATION (block);
          ilocs.safe_push (bsloc);
          if (in_system_header_at (bsloc))

I think this should either look at DECL_SOURCE_LOCATION (ao) or
at the location of the block nested in 'block'.

Note we then still warn because

  if (ilocs.length ())
    {
      /* When there is an inlining context use the macro expansion
         location for the original location and bump up NSYSLOCS if
         it's in a system header since it's not counted above.  */
      location_t sysloc = expansion_point_location_if_in_system_header (loc);
      if (sysloc != loc)

gets us the same location, failing to do

          loc = sysloc;
          ++nsyslocs;
        }

and then

  ilocs.safe_push (loc);

makes

  /* Set if all locations are in a system header.  */
  diagnostic->m_iinfo.m_allsyslocs = nsyslocs == ilocs.length ();

fail.  The logic is odd though, if it was not macro expanded it's off.

The following fixes it for me.

diff --git a/gcc/tree-diagnostic.cc b/gcc/tree-diagnostic.cc
index a660c7d0785..a49f8939ce7 100644
--- a/gcc/tree-diagnostic.cc
+++ b/gcc/tree-diagnostic.cc
@@ -328,7 +328,7 @@ set_inlining_locations (diagnostic_context *,
          if (!diagnostic->m_iinfo.m_ao)
            diagnostic->m_iinfo.m_ao = block;

-         location_t bsloc = BLOCK_SOURCE_LOCATION (block);
+         location_t bsloc = DECL_SOURCE_LOCATION (ao);
          ilocs.safe_push (bsloc);
          if (in_system_header_at (bsloc))
            ++nsyslocs;
@@ -339,17 +339,15 @@ set_inlining_locations (diagnostic_context *,
       block = BLOCK_SUPERCONTEXT (block);
     }

+  location_t sysloc;
+  /* When there is an inlining context use the macro expansion
+     location for the original location and bump up NSYSLOCS if
+     it's in a system header since it's not counted above.  */
   if (ilocs.length ())
     {
-      /* When there is an inlining context use the macro expansion
-        location for the original location and bump up NSYSLOCS if
-        it's in a system header since it's not counted above.  */
-      location_t sysloc = expansion_point_location_if_in_system_header (loc);
-      if (sysloc != loc)
-       {
-         loc = sysloc;
-         ++nsyslocs;
-       }
+      if (in_system_header_at (loc))
+       ++nsyslocs;
+      loc = expansion_point_location_if_in_system_header (loc);
     }
   else
     {

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the 2nd hunk tests OK but the first for example runs into

FAIL: gcc.dg/Wfree-nonheap-object-4.c  (test for warnings, line 19)

where we explicitly seem to expect the warning when the system header code
is inlined into non-system-header context.

That's btw the same that happens for the testcase in this bug - we inline
the has_trivial_copy_and_destroy into integrate () which isn't in a
system header.

So it seems this was a deliberate choice ... which would mean the bug at
hand is INVALID.  (-Wno-system-headers has no effect)

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 57325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57325&action=edit
patch

Patch.  Breaks expected diagnostics for inlines from system headers.

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
So invalid.