public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "slyfox at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/109514] New: [13 regression] -Werror=dangling-pointer false positive nn fheroes-1.0.3 (lambdas)
Date: Fri, 14 Apr 2023 15:33:37 +0000	[thread overview]
Message-ID: <bug-109514-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 109514
           Summary: [13 regression] -Werror=dangling-pointer false
                    positive nn fheroes-1.0.3 (lambdas)
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initially noticed the false positive on fheroes2-1.0.3 project which uses
-Werror by default. Here is the extracted example:

// $ cat screen.cpp
#include <set>
#include <vector>

struct R {
    int w;
};

typedef std::vector<R> vr_t;
typedef std::set<R> sr_t;

static sr_t FilterRs (const sr_t & rs)
{
    return rs;
}

vr_t getRs ()
{
    const vr_t filteredRs = []() {
        sr_t rs;

        rs = FilterRs (rs);

        return vr_t{rs.begin(), rs.end()};
    }();

    return filteredRs;
}

$ g++ -c -O2 screen.cpp -Werror=dangling-pointer
In file included from /<<NIX>>/gcc-13.0.0/include/c++/13.0.1/set:62,
                 from screen.cpp:1:
In member function 'void
std::_Rb_tree_header::_M_move_data(std::_Rb_tree_header&)',
    inlined from 'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_move_data(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>&, std::true_type) [with _Key = R; _Val = R; _KeyOfValue =
std::_Identity<R>; _Compare = std::less<R>; _Alloc = std::allocator<R>]' at
/<<NIX>>/gcc-13.0.0/include/c++/13.0.1/bits/stl_tree.h:1421:29,
    inlined from 'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_move_assign(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>&, std::true_type) [with _Key = R; _Val = R; _KeyOfValue =
std::_Identity<R>; _Compare = std::less<R>; _Alloc = std::allocator<R>]' at
/<<NIX>>/gcc-13.0.0/include/c++/13.0.1/bits/stl_tree.h:1710:14,
    inlined from 'std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::operator=(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&&)
[with _Key = R; _Val = R; _KeyOfValue = std::_Identity<R>; _Compare =
std::less<R>; _Alloc = std::allocator<R>]' at
/<<NIX>>/gcc-13.0.0/include/c++/13.0.1/bits/stl_tree.h:1744:21,
    inlined from 'std::set<_Key, _Compare, _Alloc>& std::set<_Key, _Compare,
_Alloc>::operator=(std::set<_Key, _Compare, _Alloc>&&) [with _Key = R; _Compare
= std::less<R>; _Alloc = std::allocator<R>]' at
/<<NIX>>/gcc-13.0.0/include/c++/13.0.1/bits/stl_set.h:302:7,
    inlined from 'getRs()::<lambda()>' at screen.cpp:21:26,
    inlined from 'vr_t getRs()' at screen.cpp:24:7:
/<<NIX>>/gcc-13.0.0/include/c++/13.0.1/bits/stl_tree.h:199:38: error: storing
the address of local variable 'rs' in '*MEM[(struct _Rb_tree_node_base *
&)&D.35566 + 16].std::_Rb_tree_node_base::_M_parent'
[-Werror=dangling-pointer=]
  199 |       _M_header._M_parent->_M_parent = &_M_header;
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
screen.cpp: In function 'vr_t getRs()':
screen.cpp:19:14: note: 'rs' declared here
   19 |         sr_t rs;
      |              ^~
screen.cpp:19:14: note: '<unnamed>.std::set<R, std::less<R>, std::allocator<R>
>::_M_t.std::_Rb_tree<R, R, std::_Identity<R>, std::less<R>, std::allocator<R>
>::_M_impl.std::_Rb_tree<R, R, std::_Identity<R>, std::less<R>,
std::allocator<R> >::_Rb_tree_impl<std::less<R>,
true>::<unnamed>.std::_Rb_tree_header::_M_header.std::_Rb_tree_node_base::_M_parent'
declared here
cc1plus: some warnings being treated as errors

I think it's a false positive (or maybe it exposes some NRVO bug?).

$ g++ -v
Using built-in specs.
COLLECT_GCC=/<<NIX>>/gcc-13.0.0/bin/g++
COLLECT_LTO_WRAPPER=/<<NIX>>/gcc-13.0.0/libexec/gcc/x86_64-unknown-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230409 (experimental) (GCC)

             reply	other threads:[~2023-04-14 15:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14 15:33 slyfox at gcc dot gnu.org [this message]
2023-04-14 17:17 ` [Bug c++/109514] " jason at gcc dot gnu.org
2023-04-15  2:19 ` cvs-commit at gcc dot gnu.org
2023-04-15  2:20 ` jason at gcc dot gnu.org
2023-04-15 17:18 ` slyfox at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-109514-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).