public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/110075] New: Bogus -Wdangling-reference
@ 2023-06-01 10:26 pilarlatiesa at gmail dot com
  2023-06-09 18:53 ` [Bug c++/110075] " pilarlatiesa at gmail dot com
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: pilarlatiesa at gmail dot com @ 2023-06-01 10:26 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 110075
           Summary: Bogus -Wdangling-reference
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

$ cat test.cpp
#include <map>
#include <string>

class T
{
  static inline std::map<std::string, int> const m = {{"foo", 0}};

public:
  static int const &Get(std::string const &s) { return m.at(s); }
};

int main()
{
  [[maybe_unused]] int const &i = T::Get("foo");
}


$ ./gcc-13/bin/g++ -Wall test.cpp
test.cpp: In function ‘int main()’:
test.cpp:14:31: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
   14 |   [[maybe_unused]] int const &i = T::Get("foo");
      |                               ^
test.cpp:14:41: note: the temporary was destroyed at the end of the full
expression ‘T::Get(std::__cxx11::basic_string<char>(((const char*)"foo"),
std::allocator<char>()))’
   14 |   [[maybe_unused]] int const &i = T::Get("foo");
      |                                   ~~~~~~^~~~~~~

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
@ 2023-06-09 18:53 ` pilarlatiesa at gmail dot com
  2023-10-28 21:26 ` roystgnr at gmail dot com
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pilarlatiesa at gmail dot com @ 2023-06-09 18:53 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Pilar Latiesa <pilarlatiesa at gmail dot com> ---
I forgot to paste:

$ ./gcc-13/bin/g++ -v
Usando especificaciones internas.
COLLECT_GCC=./gcc-13/bin/g++
COLLECT_LTO_WRAPPER=/home/pililatiesa/gcc-13/libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper
Objetivo: x86_64-pc-linux-gnu
Configurado con: ../gcc-13.1.0/configure --enable-languages=c,c++
--disable-multilib --prefix=/home/pililatiesa/gcc-13/
Modelo de hilos: posix
Algoritmos de compresión LTO admitidos: zlib
gcc versión 13.1.0 (GCC)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
  2023-06-09 18:53 ` [Bug c++/110075] " pilarlatiesa at gmail dot com
@ 2023-10-28 21:26 ` roystgnr at gmail dot com
  2024-01-19 17:25 ` mpolacek at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: roystgnr at gmail dot com @ 2023-10-28 21:26 UTC (permalink / raw)
  To: gcc-bugs

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

Roy Stogner <roystgnr at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roystgnr at gmail dot com

--- Comment #2 from Roy Stogner <roystgnr at gmail dot com> ---
This case looks most similar to the one that my code triggered, which I
simplified to the following:

---

#include <map>

const double &
find_wrapper(const std::map<int, double> & map,
             const int & key)
{
  auto it = map.find(key);
  return it->second;
}


int main(void)
{
  std::map<int, double> testmap{{1,0.0}};
  const double & d = find_wrapper(testmap, 1);
  return int(d);
}

---

$ g++ -Wall -Wextra -Werror -o test.x test.C
test.C: In function ‘int main()’:
test.C:15:18: error: possibly dangling reference to a temporary
[-Werror=dangling-reference]
   15 |   const double & d = find_wrapper(testmap, 1);
      |                  ^
test.C:15:34: note: the temporary was destroyed at the end of the full
expression ‘find_wrapper(testmap, 1)’
   15 |   const double & d = find_wrapper(testmap, 1);
      |                      ~~~~~~~~~~~~^~~~~~~~~~~~
cc1plus: all warnings being treated as errors

---

If I change the parameter type to `const int key`, then the warning is not
triggered.  If I leave the parameter type as a reference but I pass in a
non-temporary variable "one" instead of "1", then the warning is not triggered.


Either or both of these cases might be a dup of bug 109642

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
  2023-06-09 18:53 ` [Bug c++/110075] " pilarlatiesa at gmail dot com
  2023-10-28 21:26 ` roystgnr at gmail dot com
@ 2024-01-19 17:25 ` mpolacek at gcc dot gnu.org
  2024-01-24  7:50 ` ostash at ostash dot kiev.ua
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2024-01-19 17:25 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-01-19

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed, thanks for reporting.  I'm not certain I can devise a fix, but maybe
a new attribute to suppress the warning would help.  Like in bug 109642 as
mentioned.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
                   ` (2 preceding siblings ...)
  2024-01-19 17:25 ` mpolacek at gcc dot gnu.org
@ 2024-01-24  7:50 ` ostash at ostash dot kiev.ua
  2024-01-24 15:51 ` mpolacek at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: ostash at ostash dot kiev.ua @ 2024-01-24  7:50 UTC (permalink / raw)
  To: gcc-bugs

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

Viktor Ostashevskyi <ostash at ostash dot kiev.ua> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ostash at ostash dot kiev.ua

--- Comment #4 from Viktor Ostashevskyi <ostash at ostash dot kiev.ua> ---
I have even simpler reproducer:

---
class X{};
const X x1;
const X x2;

const X& get(const int& i)
{
   return i == 0 ? x1 : x2;
}

void foo() {
    [[maybe_unused]] const X& x = get(10);
}
---

<source>: In function 'void foo()':
<source>:23:31: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
   23 |     [[maybe_unused]] const X& x = get(10);
      |                               ^
<source>:23:38: note: the temporary was destroyed at the end of the full
expression 'get(10)'
   23 |     [[maybe_unused]] const X& x = get(10);
      |

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
                   ` (3 preceding siblings ...)
  2024-01-24  7:50 ` ostash at ostash dot kiev.ua
@ 2024-01-24 15:51 ` mpolacek at gcc dot gnu.org
  2024-01-28 16:21 ` ostash at ostash dot kiev.ua
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2024-01-24 15:51 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Yes, because we'd have to analyze the body of the function to see that it does
not return one of the parameters, which often we can't do.

There will be an attribute soon to suppress that warning.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
                   ` (4 preceding siblings ...)
  2024-01-24 15:51 ` mpolacek at gcc dot gnu.org
@ 2024-01-28 16:21 ` ostash at ostash dot kiev.ua
  2024-01-30 16:44 ` mpolacek at gcc dot gnu.org
  2024-03-01 21:18 ` mpolacek at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: ostash at ostash dot kiev.ua @ 2024-01-28 16:21 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Viktor Ostashevskyi <ostash at ostash dot kiev.ua> ---
(In reply to Marek Polacek from comment #5)
> Yes, because we'd have to analyze the body of the function to see that it
> does not return one of the parameters, which often we can't do.
> 
> There will be an attribute soon to suppress that warning.

I'm wondering whether this diagnostics should be in -Wall or -Wextra at all.
It is assumed that diagnostics in -Wall or -Wextra generally "works".

Here, diagnostics clearly fails on simplest case and I don't think marking huge
codebase with some attribute is a proper solution...

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
                   ` (5 preceding siblings ...)
  2024-01-28 16:21 ` ostash at ostash dot kiev.ua
@ 2024-01-30 16:44 ` mpolacek at gcc dot gnu.org
  2024-03-01 21:18 ` mpolacek at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2024-01-30 16:44 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
It's hard to decide.  It seems that once we've covered std::span-like classes,
in practice the warning points out real issues.  I would hope that code like
you posted is actually fairly rare.  But it's difficult to be sure.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug c++/110075] Bogus -Wdangling-reference
  2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
                   ` (6 preceding siblings ...)
  2024-01-30 16:44 ` mpolacek at gcc dot gnu.org
@ 2024-03-01 21:18 ` mpolacek at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2024-03-01 21:18 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
In r14-9263-gc7607c4cf18986 I added [[gnu::no_dangling]] which can be used to
suppress the warning in cases where the compiler can't detect that the
reference doesn't actually dangle.

Hopefully that'll work.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-03-01 21:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-01 10:26 [Bug c++/110075] New: Bogus -Wdangling-reference pilarlatiesa at gmail dot com
2023-06-09 18:53 ` [Bug c++/110075] " pilarlatiesa at gmail dot com
2023-10-28 21:26 ` roystgnr at gmail dot com
2024-01-19 17:25 ` mpolacek at gcc dot gnu.org
2024-01-24  7:50 ` ostash at ostash dot kiev.ua
2024-01-24 15:51 ` mpolacek at gcc dot gnu.org
2024-01-28 16:21 ` ostash at ostash dot kiev.ua
2024-01-30 16:44 ` mpolacek at gcc dot gnu.org
2024-03-01 21:18 ` mpolacek at gcc dot gnu.org

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).