From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1BA21385801D; Thu, 17 Feb 2022 08:01:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1BA21385801D From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern Date: Thu, 17 Feb 2022 08:01:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: qinzhao at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Thu, 17 Feb 2022 08:01:06 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104550 --- Comment #13 from rguenther at suse dot de --- On Wed, 16 Feb 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104550 >=20 > Jakub Jelinek changed: >=20 > What |Removed |Added > -------------------------------------------------------------------------= --- > CC| |jakub at gcc dot gnu.org >=20 > --- Comment #8 from Jakub Jelinek --- > Well, for the .DEFERRED_INIT case if the var ends up in memory, I really = don't > see the point in any clear_padding, .DEFERRED_INIT expansion should just > initialize the whole DECL_RTL MEM_P slot with the pattern it wants, tryin= g to > initialize only the non-padding bits and then only the padding bits next = to > each other is a waste of CPU cycles. > Another case are C++ vars with non-trivial ctors, if we for -flifetime-ds= e=3D2 > emit CLOBBERs at the start of such ctors, then IMNSHO the right thing is = to > emit the zero or pattern initialization in those constructors, perhaps th= rough > .DEFERRED_INIT. > This is the start_preparsed_function > if (!processing_template_decl > && (flag_lifetime_dse > 1) > && DECL_CONSTRUCTOR_P (decl1) > && !DECL_CLONED_FUNCTION_P (decl1) > /* Clobbering an empty base is harmful if it overlays real data. */ > && !is_empty_class (current_class_type) > /* We can't clobber safely for an implicitly-defined default constr= uctor > because part of the initialization might happen before we enter = the > constructor, via AGGR_INIT_ZERO_FIRST (c++/68006). */ > && !implicit_default_ctor_p (decl1)) > finish_expr_stmt (build_clobber_this ()); > case. Advantage of doing it in the ctor is that if it isn't inlined, it = is > done just once per type, doesn't need to be duplicated in all the spots t= hat > use it. > Of course, if the above conditions aren't met, then it still needs to be > initialized somewhere else like where it is done currently, or for the ca= se of > vars with constructors for which we don't emit it perhaps do > __builtin_clear_padding after the constructor (but can we be sure that th= e ctor > hasn't e.g. performed placement new and built in itself some other class?= ). >=20 > Anyway, doing __builtin_clear_padding at RTL expansion time might be > non-trivial. One thing we still haven't decided on what to do with the v= irtual > inheritance, whether we need a langhook which won't be there at expansion= time, > or if we can just use binfo (but doesn't free_lang_data mess up with binfo > too)? > And right now the code has two main possibilities, either emit gimple cod= e to > do the clearing, or set a padding bitmask in memory. For RTL, either one= could > use the latter and turn that into RTL code clearing, or we would need a t= hird > mode in which it would be emitting RTL directly. Emitting such code earl= y has > the advantage of store-merging and all kinds of other optimizations thoug= h... There's also the option to do .DEFERRED_INIT expansion on GIMPLE=20 somewhere, maybe in ISEL. But sure, if padding clearing needs a langhook that's a no-go. BINFOs are preserved to the extent needed for devirtualization. I suppose the mask could also be precomputed and stuck into the .DEFERRED_INIT call itself somehow ... (encoded into some sequence of variable number of args? , , ,=20 , 0)=