From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3D1C13858D33; Tue, 24 Jan 2023 17:38:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3D1C13858D33 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674581907; bh=qMrYWIzu+5UopxK2X0RbzRrfyyS5I8EmOgBn3IPWyUs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Pa3qmYbEkzwzDru/vH1XD2A4mP6AtQIxdNffpLZcmPt1sD5FF96+NJa2vdepkVXAZ owuT6BvQU6+GdHu6QqekpAzZ6wNN/FutHrI1IqcJ3T9S8iKvtfELl2pY3ediI+Uq1M kxGLqBDfMSSnYQA59MvQfHT08arhtcx3qoNJX0XA= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1 Date: Tue, 24 Jan 2023 17:38:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107532 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 b= ind 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 alloc= ated Plane and return a reference to that and then deallocate it in the destruct= or (it would then be a dangling reference that with the change wouldn't be war= ned about), or on the other side, e.g. if the possibly dangling reference is const Whateve= r & 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 hap= pen to have that type.=