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

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

[slyfox at gcc dot gnu.org]

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

            Bug ID: 107532
           Summary: [13 Regression] -Werror=dangling-reference false
                    positives in libcamera-0.0.1
           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
                CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

libcamera-0.0.1 and a few other projects (like cvise) fail to compile due to
-Werror on -Werror=dangling-reference.

I think those are false positives related to value-like types that pass
references through.

Extracted example from libcamera:

// $ cat a.cpp.cpp

struct Plane { unsigned int bytesused; };

// Passes a reference through. Does not change lifetime.
template <typename Inner>
struct Ref {
    const Inner & i_;
    Ref(const Inner & i) : i_(i) {}
    const Inner & inner() { return i_; }
};

struct FrameMetadata {
    Ref<const Plane> planes() const { return p_; }

    Plane p_;
};

void bar(const Plane & meta);
void foo(const FrameMetadata & fm)
{
    const Plane & meta = fm.planes().inner();
    bar(meta);
}

$ g++-13.0.0 -c -Wall -Werror=dangling-reference a.cpp
a.cpp: In function 'void foo(const FrameMetadata&)':
a.cpp:20:19: error: possibly dangling reference to a temporary
[-Werror=dangling-reference]
   20 |     const Plane & meta = fm.planes().inner();
      |                   ^~~~
a.cpp:20:43: note: the temporary was destroyed at the end of the full
expression '(& fm)->FrameMetadata::planes().Ref<const Plane>::inner()'
   20 |     const Plane & meta = fm.planes().inner();
      |                          ~~~~~~~~~~~~~~~~~^~
cc1plus: some warnings being treated as errors

This gcc version is this week's gcc-13 snapshot with
https://gcc.gnu.org/PR107488 applied on top.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> 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

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
@Marek: Any progress on this, please?

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

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
@Marek: PING

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Sorry about the long delay.  Unfortunately I'm not sure yet how to fix it.

We have
Ref<const Plane>::inner (&TARGET_EXPR <D.2839, FrameMetadata::planes ((const
struct FrameMetadata *) fm)>)

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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<Plane>) 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]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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
<https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610353.html>.

> 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<Plane>) 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]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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]

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
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

[pobrn at protonmail dot com]

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

Barnabás Pőcze <pobrn at protonmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pobrn at protonmail dot com

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

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

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

[ecurtin at redhat dot com]

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Sorry.  A patch is on review.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

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

commit r13-6529-g80f0052b3924569af904d1bab0858fe985f33a94
Author: Marek Polacek <polacek@redhat.com>
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<std::string>.

    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]

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

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

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

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.

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

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
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

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 54621
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54621&action=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

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Hmm, so it's this line

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

and we complain because we have

libcamera::Span<const libcamera::FrameMetadata::Plane>::operator[]
(&TARGET_EXPR <D.153699, libcamera::FrameMetadata::planes ((const struct
FrameMetadata *) libcamera::FrameBuffer::metadata (NON_LVALUE_EXPR
<VIEW_CONVERT_EXPR<struct FrameBuffer *>(buffer)>))>, (size_type)
VIEW_CONVERT_EXPR<unsigned int>(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

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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

[pobrn at protonmail dot com]

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

--- Comment #17 from Barnabás Pőcze <pobrn at protonmail dot com> ---
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

[mpolacek at gcc dot gnu.org]

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

--- Comment #18 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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

[mpolacek at gcc dot gnu.org]

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

--- Comment #19 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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

[eike@sf-mail.de]

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

--- Comment #20 from Rolf Eike Beer <eike@sf-mail.de> ---
I'm running this rev:

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

And I still get a warning for this testcase:

// $ cat ref.cpp
#include <string>

const std::string &trigger(const std::string &server);

int verifyDevXml()
{
  const auto &str = 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 &str = trigger("");
      |               ^~~
ref.cpp:7:28: note: the temporary was destroyed at the end of the full
expression ?trigger(std::__cxx11::basic_string<char>(((const char*)""),
std::allocator<char>()))?
    7 |   const auto &str = 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

[flast at flast dot jp]

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

--- Comment #21 from Kohei Takahashi <flast at flast dot jp> ---
(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<T&...> 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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

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

commit r13-6633-gced122b849b8961b854053f0d1ac96983c5802e5
Author: Marek Polacek <polacek@redhat.com>
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

[mpolacek at gcc dot gnu.org]

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

--- Comment #23 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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<T&...>
> 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

[flast at flast dot jp]

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

--- Comment #24 from Kohei Takahashi <flast at flast dot jp> ---
(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<T&...>
> > 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]

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

--- Comment #25 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
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

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #26 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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<T&...>
> > > 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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

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

commit r13-6830-g59bfdd5f467292a368d0d628084a4b65d1bb06bb
Author: Marek Polacek <polacek@redhat.com>
Date:   Fri Mar 17 14:36:10 2023 -0400

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

    Based on <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532#c24>,
    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<int&>(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]

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

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

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

--- Comment #28 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed some more.

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

[gcc-bugzilla at al42and dot me]

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

--- Comment #29 from Andrey Alekseenko <gcc-bugzilla at al42and dot me> ---
> 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()
{
    int        a;
    const int& r = ArrayRef(&a)[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(&a)[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(&a)[0];
      |                                  ^

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

[gnu.ojxq8 at dralias dot com]

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

--- Comment #30 from maic <gnu.ojxq8 at dralias dot com> ---
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 &Select(const int &i, const bool &b) { return i; }
int main() {
  int a;
  const auto &b{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 &b{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 &b{Select(a, true)};
      |                 ~~~~~~^~~~~~~~~

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

[gnu.ojxq8 at dralias dot com]

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

--- Comment #31 from maic <gnu.ojxq8 at dralias dot com> ---
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

[mpolacek at gcc dot gnu.org]

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

--- Comment #32 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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

[cuzdav at gmail dot com]

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

Chris Uzdavinis <cuzdav at gmail dot com> changed:

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

--- Comment #33 from Chris Uzdavinis <cuzdav at gmail dot com> ---
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

[boris at kolpackov dot net]

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

Boris Kolpackov <boris at kolpackov dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |boris at kolpackov dot net

--- Comment #34 from Boris Kolpackov <boris at kolpackov dot net> ---
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

[mpolacek at gcc dot gnu.org]

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

--- Comment #35 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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.