[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #35 from Marek Polacek  ---
(In reply to Boris Kolpackov from comment #34)
> Would like to echo other's comments: getting a large number false positives
> in our codebase (build2). Thankfully this warning seems to only be enabled
> with -Wextra and not with -Wall as stated in #106393.

Yup.  I'm also planning to add a bunch of tweaks to significantly reduce the
number of false positives (and devise a way for users to easily suppress the
warning by adding a pragma around the class).  That work ought to happen in GCC
14.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[boris at kolpackov dot net via Gcc-bugs]

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

Boris Kolpackov  changed:

   What|Removed |Added

 CC||boris at kolpackov dot net

--- Comment #34 from Boris Kolpackov  ---
Would like to echo other's comments: getting a large number false positives in
our codebase (build2). Thankfully this warning seems to only be enabled with
-Wextra and not with -Wall as stated in #106393.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[cuzdav at gmail dot com via Gcc-bugs]

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

Chris Uzdavinis  changed:

   What|Removed |Added

 CC||cuzdav at gmail dot com

--- Comment #33 from Chris Uzdavinis  ---
Could an attribute or annotation be added so we can mark our classes to opt-out
of this warning for them?

I like the warning in general but it is hitting one of our core "span-like"
classes that stores pointers, and is going off so much that I'm going to need
to disable it.  I'd be much happier disabling it on a per-object basis, rather
than globally.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #32 from Marek Polacek  ---
(In reply to maic from comment #31)
> Would be nice if this was re-opened, or should a new bug be filed?

This is the same problem as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165#c9

Unfortunately, it's not feasible to fix it in the front end, sorry about that.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

--- Comment #31 from maic  ---
Would be nice if this was re-opened, or should a new bug be filed?

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[gnu.ojxq8 at dralias dot com via Gcc-bugs]

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

--- Comment #30 from maic  ---
This bug still exists for our project. To reproduce:


# g++ --version 
g++ (GCC) 13.0.1 20230404 (Red Hat 13.0.1-0)


# cat /tmp/2.cpp 
const int (const int , const bool ) { return i; }
int main() {
  int a;
  const auto {Select(a, true)};
}


# g++ -Wdangling-reference /tmp/2.cpp 
/tmp/2.cpp: In function ‘int main()’:
/tmp/2.cpp:4:15: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
4 |   const auto {Select(a, true)};
  |   ^
/tmp/2.cpp:4:23: note: the temporary was destroyed at the end of the full
expression ‘Select(a, true)’
4 |   const auto {Select(a, true)};
  | ~~^

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[gcc-bugzilla at al42and dot me via Gcc-bugs]

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

--- Comment #29 from Andrey Alekseenko  ---
> it seems like we should treat *any* class with a reference member as a 
> reference wrapper. 

And any class with a pointer, I suspect.

This is a reduced/simplified example from our codebase still triggering the
error even with 59bfdd5f467292a368d0d628084a4b65d1bb06bb:

$ cat test.cpp 
struct ArrayRef
{
ArrayRef(int* ptr) : ptr_(ptr) {}
int& operator[](int n) const { return ptr_[n]; }
int* ptr_;
};

int main()
{
inta;
const int& r = ArrayRef()[0];
}

$ g++ -std=c++17 -Wdangling-reference test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:11:16: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
   11 | const int& r = ArrayRef()[0];
  |^
test.cpp:11:34: note: the temporary was destroyed at the end of the full
expression ‘ArrayRef((& a)).ArrayRef::operator[](0)’
   11 | const int& r = ArrayRef()[0];
  |  ^

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #28 from Marek Polacek  ---
Fixed some more.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #27 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:59bfdd5f467292a368d0d628084a4b65d1bb06bb

commit r13-6830-g59bfdd5f467292a368d0d628084a4b65d1bb06bb
Author: Marek Polacek 
Date:   Fri Mar 17 14:36:10 2023 -0400

c++: further -Wdangling-reference refinement [PR107532]

Based on ,
it seems like we should treat *any* class with a reference member
as a reference wrapper.  To suppress the warning in

  int i = 42;
  auto const& v = std::get<0>(std::tuple(i));

we have to look into base classes as well.  For std::tuple, this means
that we have to check the _Head_base subobject, which is a non-direct
base class of std::tuple.  So I've employed a DFS walk.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (class_has_reference_member_p): New.
(class_has_reference_member_p_r): New.
(reference_like_class_p): Don't look for a specific constructor.
Use a DFS walk with class_has_reference_member_p_r.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference11.C: New test.
* g++.dg/warn/Wdangling-reference12.C: New test.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|ASSIGNED

--- Comment #26 from Marek Polacek  ---
(In reply to Kohei Takahashi from comment #24)
> (In reply to Marek Polacek from comment #23)
> > (In reply to Kohei Takahashi from comment #21)
> > > (In reply to Marek Polacek from comment #18)
> > > > (In reply to Barnabás Pőcze from comment #17)
> > > > > The simple test case with std::span still triggers the warning:
> > > > > https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> > > > > analysis such a warning will generate too many false positives and 
> > > > > people
> > > > > will simply turn it off.
> > > > 
> > > > There really haven't been that many, except this and one with 
> > > > range-based
> > > > for loops.
> > > 
> > > I think it warns many usage of zip_iterator idiom such as boost.iterator 
> > > and
> > > P2321 style flat_map. Those uses tuple of references like 
> > > std::tuple
> > > by dereferencing iterator, so that any algorithms may yield this warning.
> > 
> > Ah, would you please have a testcase?  If that's the case and the warning
> > can't be taught to recognize that pattern, then I think we need to move it
> > to -Wextra.  Thanks.
> 
> In my flat map implementation, https://github.com/Flast/flat_map, the
> warning is shown here
> https://github.com/Flast/flat_map/blob/
> f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/__flat_tree.hpp#LL435C42-
> L435C52 . You can reproduce it by following
> ```
> flat_map$ mkdir build
> flat_map$ cd build
> flat_map/build$ cmake ..
> flat_map/build$ make map_tie_test_17
> ```
> 
> `_key_extractor` is defined here,
> https://github.com/Flast/flat_map/blob/
> f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/flat_map.hpp#L89-L90, and
> the iterator dereference is here,
> https://github.com/Flast/flat_map/blob/
> f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/tied_sequence.hpp#L67-L72.
> Hence, reduced code is like https://wandbox.org/permlink/DloAyU3dQgydo7PS,
> or https://wandbox.org/permlink/7fM4NDF8u1hiRMFC.

Thanks for those reduced testcases.  I may be able to fix the warning there.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #25 from Marek Polacek  ---
Maybe it would help to say that *any* class that has a reference member is a
reference-wrapper and don't warn.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[flast at flast dot jp via Gcc-bugs]

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

--- Comment #24 from Kohei Takahashi  ---
(In reply to Marek Polacek from comment #23)
> (In reply to Kohei Takahashi from comment #21)
> > (In reply to Marek Polacek from comment #18)
> > > (In reply to Barnabás Pőcze from comment #17)
> > > > The simple test case with std::span still triggers the warning:
> > > > https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> > > > analysis such a warning will generate too many false positives and 
> > > > people
> > > > will simply turn it off.
> > > 
> > > There really haven't been that many, except this and one with range-based
> > > for loops.
> > 
> > I think it warns many usage of zip_iterator idiom such as boost.iterator and
> > P2321 style flat_map. Those uses tuple of references like std::tuple
> > by dereferencing iterator, so that any algorithms may yield this warning.
> 
> Ah, would you please have a testcase?  If that's the case and the warning
> can't be taught to recognize that pattern, then I think we need to move it
> to -Wextra.  Thanks.

In my flat map implementation, https://github.com/Flast/flat_map, the warning
is shown here
https://github.com/Flast/flat_map/blob/f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/__flat_tree.hpp#LL435C42-L435C52
. You can reproduce it by following
```
flat_map$ mkdir build
flat_map$ cd build
flat_map/build$ cmake ..
flat_map/build$ make map_tie_test_17
```

`_key_extractor` is defined here,
https://github.com/Flast/flat_map/blob/f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/flat_map.hpp#L89-L90,
and the iterator dereference is here,
https://github.com/Flast/flat_map/blob/f7d547fd4dbde763c07eb8d35796248c41989a66/flat_map/tied_sequence.hpp#L67-L72.
Hence, reduced code is like https://wandbox.org/permlink/DloAyU3dQgydo7PS, or
https://wandbox.org/permlink/7fM4NDF8u1hiRMFC.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from Marek Polacek  ---
(In reply to Kohei Takahashi from comment #21)
> (In reply to Marek Polacek from comment #18)
> > (In reply to Barnabás Pőcze from comment #17)
> > > The simple test case with std::span still triggers the warning:
> > > https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> > > analysis such a warning will generate too many false positives and people
> > > will simply turn it off.
> > 
> > There really haven't been that many, except this and one with range-based
> > for loops.
> 
> I think it warns many usage of zip_iterator idiom such as boost.iterator and
> P2321 style flat_map. Those uses tuple of references like std::tuple
> by dereferencing iterator, so that any algorithms may yield this warning.

Ah, would you please have a testcase?  If that's the case and the warning can't
be taught to recognize that pattern, then I think we need to move it to
-Wextra.  Thanks.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:ced122b849b8961b854053f0d1ac96983c5802e5

commit r13-6633-gced122b849b8961b854053f0d1ac96983c5802e5
Author: Marek Polacek 
Date:   Fri Mar 10 12:23:13 2023 -0500

c++: suppress -Wdangling-reference for std::span [PR107532]

std::span is a view and therefore should be treated as a reference
wrapper class for the purposes of -Wdangling-reference.  I'm not sure
there's a pattern that we could check for.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (reference_like_class_p): Check for std::span.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference10.C: New test.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[flast at flast dot jp via Gcc-bugs]

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

--- Comment #21 from Kohei Takahashi  ---
(In reply to Marek Polacek from comment #18)
> (In reply to Barnabás Pőcze from comment #17)
> > The simple test case with std::span still triggers the warning:
> > https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> > analysis such a warning will generate too many false positives and people
> > will simply turn it off.
> 
> There really haven't been that many, except this and one with range-based
> for loops.

I think it warns many usage of zip_iterator idiom such as boost.iterator and
P2321 style flat_map. Those uses tuple of references like std::tuple by
dereferencing iterator, so that any algorithms may yield this warning.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[eike--- via Gcc-bugs]

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

--- Comment #20 from Rolf Eike Beer  ---
I'm running this rev:

g++-13 (Gentoo 13.0.1. p, commit 27495bc8fe028d4a68e97ad12b52231772e48dcf)
13.0.1 20230308 (experimental)

And I still get a warning for this testcase:

// $ cat ref.cpp
#include 

const std::string (const std::string );

int verifyDevXml()
{
  const auto  = trigger("");

  if (str.empty())
return 1;

  return 0;
}
// $ g++-13 -Wdangling-reference -c -o ref.o ref.cpp
ref.cpp: In function ?int verifyDevXml()?:
ref.cpp:7:15: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
7 |   const auto  = trigger("");
  |   ^~~
ref.cpp:7:28: note: the temporary was destroyed at the end of the full
expression ?trigger(std::__cxx11::basic_string(((const char*)""),
std::allocator()))?
7 |   const auto  = trigger("");
  | ~~~^~~~

The problem is to my understanding that this warns about the temporary
constructed in the argument, i.e. it warns that the std::string() formed from
"" could be bound here. Which could be true if the function does that, but in
my case it is just used as a lookup for a map and not returned.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from Marek Polacek  ---
(In reply to Barnabás Pőcze from comment #17)
> The simple test case with std::span still triggers the warning:
> https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> analysis such a warning will generate too many false positives and people
> will simply turn it off.

...but I could at least add a std::span check to fix this test...

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Marek Polacek  ---
(In reply to Jonathan Wakely from comment #16)
> Span is a view, so it is like reference-wrapper. The lifetime of the
> underlying data is not tied to the lifetime of the Span.

Aha, I could add a check for std::span but that wouldn't help, because here
it's a custom-made Span.  And I don't think there's a pattern I could look for
that would tell us "this is a std::span-like class".  :/

(In reply to Barnabás Pőcze from comment #17)
> The simple test case with std::span still triggers the warning:
> https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code
> analysis such a warning will generate too many false positives and people
> will simply turn it off.

There really haven't been that many, except this and one with range-based for
loops.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[pobrn at protonmail dot com via Gcc-bugs]

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

--- Comment #17 from Barnabás Pőcze  ---
The simple test case with std::span still triggers the warning:
https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code analysis
such a warning will generate too many false positives and people will simply
turn it off.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Jonathan Wakely  ---
Span is a view, so it is like reference-wrapper. The lifetime of the underlying
data is not tied to the lifetime of the Span.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Marek Polacek  ---
Hmm, so it's this line

const FrameMetadata::Plane  = buffer->metadata().planes()[i];

and we complain because we have

libcamera::Span::operator[]
(_EXPR (buffer)>))>, (size_type)
VIEW_CONVERT_EXPR(i))

and the argument to operator[] is a temporary of type Span.  Span is not a
reference wrapper class so I *think* this is a valid warning.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Martin Liška  ---
Created attachment 54621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54621=edit
Unreduced test-case

Marek, can you please check if the unreduced test-case is a false-positive of
the warning or a real problem?

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Martin Liška  ---
I can confirm the reduced test-case is fixed, however the original file is
still not. I've created: https://bugs.libcamera.org/show_bug.cgi?id=185

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Marek Polacek  ---
Fixed.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:80f0052b3924569af904d1bab0858fe985f33a94

commit r13-6529-g80f0052b3924569af904d1bab0858fe985f33a94
Author: Marek Polacek 
Date:   Tue Jan 17 17:34:58 2023 -0500

c++: -Wdangling-reference with reference wrapper [PR107532]

Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

  const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

This patch adjusts do_warn_dangling_reference so that we look through
reference wrapper classes (meaning, has a reference member and a
constructor taking the same reference type, or is std::reference_wrapper
or std::ranges::ref_view) and don't warn for them, supposing that the
member function returns a reference to a non-temporary object.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (reference_like_class_p): New.
(do_warn_dangling_reference): Add new bool parameter.  See through
reference_like_class_p.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference8.C: New test.
* g++.dg/warn/Wdangling-reference9.C: New test.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Marek Polacek  ---
Sorry.  A patch is on review.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[ecurtin at redhat dot com via Gcc-bugs]

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

ecurtin at redhat dot com changed:

   What|Removed |Added

 CC||ecurtin at redhat dot com

--- Comment #9 from ecurtin at redhat dot com ---
This is still causing problems in Fedora 38 onwards

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[pobrn at protonmail dot com via Gcc-bugs]

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

Barnabás Pőcze  changed:

   What|Removed |Added

 CC||pobrn at protonmail dot com

--- Comment #8 from Barnabás Pőcze  ---
Here is another very simple example that only uses STL types:
https://gcc.godbolt.org/z/43cKxdqr3

  void f(const std::vector& v)
  {
  const int& r = std::span(v)[0];
  }

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Marek Polacek  ---
Sadly, I'm pretty certain it won't get fixed by P2718R0.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #5)
> It's tricky.  I've seen unfixable problems with range-based for loops, for
> instance.

Shouldn't those be fixed once P2718R0 is implemented (at least for C++23)?

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #4)
> Yeah, without analyzing what the function call (constructor in this case)
> actually does
> hard to say whether the warning is ok or not.
> Maybe some heuristics based on the types?

Yes, I'm about to post another patch in response to
.

> The reference in question is const Plane &, so see if the reference could
> bind to some member of the class that is destructed at the end of the
> statement (Ref) or the class itself?
> Even with that there can be false positives and false negatives,
> e.g. the to be destructed temporary could contain a pointer to a heap
> allocated Plane and return a reference to that and then deallocate it in the
> destructor (it would then be a dangling reference that with the change
> wouldn't be warned about), or
> on the other side, e.g. if the possibly dangling reference is const Whatever
> &
> and the temporary is Whatever, it might be likely that the reference is to
> the
> temporary, but it could be just a value of some member of it that would
> happen to have that type.

It's tricky.  I've seen unfixable problems with range-based for loops, for
instance.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah, without analyzing what the function call (constructor in this case)
actually does
hard to say whether the warning is ok or not.
Maybe some heuristics based on the types?
The reference in question is const Plane &, so see if the reference could bind
to some member of the class that is destructed at the end of the statement
(Ref) or the class itself?
Even with that there can be false positives and false negatives,
e.g. the to be destructed temporary could contain a pointer to a heap allocated
Plane and return a reference to that and then deallocate it in the destructor
(it would then be a dangling reference that with the change wouldn't be warned
about), or
on the other side, e.g. if the possibly dangling reference is const Whatever &
and the temporary is Whatever, it might be likely that the reference is to the
temporary, but it could be just a value of some member of it that would happen
to have that type.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Marek Polacek  ---
Sorry about the long delay.  Unfortunately I'm not sure yet how to fix it.

We have
Ref::inner (_EXPR )

which returns a ref and its arg is a temporary.

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Martin Liška  ---
@Marek: PING

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Martin Liška  ---
@Marek: Any progress on this, please?

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Last reconfirmed||2022-11-11
 Status|UNCONFIRMED |ASSIGNED

[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0