From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 28DDE385AC28; Mon, 16 Aug 2021 19:18:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 28DDE385AC28 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/101831] Spurious maybe-uninitialized warning on std::array::size Date: Mon, 16 Aug 2021 19:18:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.1.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc everconfirmed cf_reconfirmed_on 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 19:18:21 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101831 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |msebor at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed| |2021-08-16 --- Comment #1 from Martin Sebor --- -Wmaybe-uninitialized is also issued when an uninitialized object is passed= by reference to a const-qualified argument. This includes passing the address= of an such object to the implicit this pointer in calls to member functions. = This form of the warning runs very early on and before any function calls have b= een inlined, so it can't tell that the function doesn't actually read from the uninitialized object. The same effect can be reproduced in C in a call to a non-member function (see below). It's possible to run the early uninitiali= zed pass later but probably not without introducing some false negatives. I'm = not sure that the std::array use case is common enough to justify the potential for the false negatives (or conversely, that the potential is significant enough not to avoid the false positives). So confirmed. It requires some thought and testing. $ cat a.c && gcc -S -Wall -Wextra a.c inline __attribute__ ((always_inline)) int f (const int *p) { (void)&p; return 0; } int g (void) { int i; return f (&i); } a.c: In function =E2=80=98g=E2=80=99: a.c:7:10: warning: =E2=80=98i=E2=80=99 may be used uninitialized [-Wmaybe-u= ninitialized] 7 | return f (&i); | ^~~~~~ a.c:2:5: note: by argument 1 of type =E2=80=98const int *=E2=80=99 to =E2= =80=98f=E2=80=99 declared here 2 | int f (const int *p) { (void)&p; return 0; } | ^ a.c:6:7: note: =E2=80=98i=E2=80=99 declared here 6 | int i; | ^=