From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 999203858408; Wed, 16 Feb 2022 15:38:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 999203858408 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern Date: Wed, 16 Feb 2022 15:38:12 +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: jakub at gcc dot gnu.org 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: 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 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: Wed, 16 Feb 2022 15:38:12 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104550 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Well, for the .DEFERRED_INIT case if the var ends up in memory, I really do= n'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, trying = 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-dse= =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 thro= ugh .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 construc= tor 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 that 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 case= 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 the = ctor hasn't e.g. performed placement new and built in itself some other class?). 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 vir= tual inheritance, whether we need a langhook which won't be there at expansion t= ime, 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 code = to do the clearing, or set a padding bitmask in memory. For RTL, either one c= ould use the latter and turn that into RTL code clearing, or we would need a thi= rd mode in which it would be emitting RTL directly. Emitting such code early = has the advantage of store-merging and all kinds of other optimizations though.= ..=