From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A09473857B93; Wed, 15 Feb 2023 15:28:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A09473857B93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1676474929; bh=s3vBoPWhQx0jtCea4LvTjSYzko7+jWmQHH301RZdXoA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k0f13xGwQMUQMS61GObo05He7qGQsVUNmlLNxkKKryE+hyhokKSQVZqoO74r3Fyka fBZX9sKq0cun2V3C//ZndnHE9qK0OJQ14LeGWXtYLwMS7ef7xkaw4G9byI1ZdczsLk Ra89n8bYjSqK+HHTFXxabPyJ9FUDD78pc8YB498k= From: "jamborm at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null" Date: Wed, 15 Feb 2023 15:28:47 +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: jamborm 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: 11.4 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=3D108517 Martin Jambor changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #8 from Martin Jambor --- (In reply to Jakub Jelinek from comment #6) > Somehow this constprop function is kept in the IL but not really called by > anything once IPA passes are done. This is discovered only when performing inlining on GIMPLE bodies, I guess during folding of the conditions. At this point, with LTO, the constprop functions could theoretically be in another partition so generally it is too late to remove them as unreachable. (In reply to Jakub Jelinek from comment #7) > Or perhaps when considering the constprop see that for __first_5(D) being= 0B > there would be pointer arithmetics on NULL (the __first_5(D) p+ 16) and so > would invoke UB or likely invoke UB and so not worth constant propagation. Only when unguarded. Being able to eliminate these when they are guarded by a NULL check is something that IPA-CP should do. And NULL checks can be non-obvious at IPA time, in this case this is essentially done by the check that if (__first_4(D) !=3D __last_5(D)) where we manage to prove that __first is zero but __last can be either zero or zero pointer_plus 16 and therefore we fail to propagate (for all contexts). I'm afraid I don't have any good ideas that might not lead to adverse effects in other situations. Perhaps we could specifically track such comparisons in a bitmap and then do some "likely invalid pointer" propagation for pointer arithmetics and then avoid cloning for zero value in presence of such comparisons...=