From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id DCBC83858D29 for ; Tue, 8 Dec 2020 07:35:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DCBC83858D29 Received: by mail-ej1-x62c.google.com with SMTP id bo9so23153290ejb.13 for ; Mon, 07 Dec 2020 23:35:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EiOHM4k5YFmGslW8IIczgVZ5xSFXv+8c5aiiNgUVoaI=; b=chjpz3/NWy7qnsdyzEv6qoFoohLQxJItFVQkieASvajmj9aM9OEMzTOoPuWPshJHYt ebgJhJzsEANefovm+JcxARmyzhWtcZElcrddupx87SF/UKyOHcJeiR9Owh96Md/VU9c9 5DuY+oMR1DBY+EfFYBVOQpxlqsnqelLesogmJGrkltYprZklP/T0YH6jIZQtSls+31/E 0fxeG4IrOcL/6INIgupGXXkK89fXdyY7qOQ8TAS7k4emq1jaWsyqVeG1UEHiAiwHndMy QjzQBO99P4I6rnMDny9kTzsyHnIb6HQ0O+kZ1wPhyo3fSHVPTclbEFhD6mKgyaQBCUUX a0HA== X-Gm-Message-State: AOAM533Vp5h9IQPduY9kX8HIIl7N1t/HYmzrYWIf60ZGv0lJL7r6k+iW UM1e1Vg1fTlh62/Cg5KMy64UbvFZO2i4wkTmKiFeonH5 X-Google-Smtp-Source: ABdhPJyv93bst7s6CPkDETBAyF607V6R6cCH1wDvkMtvrAGrXSMmZl4pm68miakec7xvQI3o+HPY/zDFYscO9qL9HAM= X-Received: by 2002:a17:906:edd1:: with SMTP id sb17mr15697435ejb.118.1607412915889; Mon, 07 Dec 2020 23:35:15 -0800 (PST) MIME-Version: 1.0 References: <217BE64F-A623-4453-B45B-D38B66B71B72@ORACLE.COM> <33955130-9D2D-43D5-818D-1DCC13FC1988@ORACLE.COM> <89D58812-0F3E-47AE-95A5-0A07B66EED8C@ORACLE.COM> <23B74D40-BB4F-46AF-94A5-E490585CCCC0@ORACLE.COM> <02D89618-9C78-4560-84B0-61E5C8830E7D@ORACLE.COM> In-Reply-To: <02D89618-9C78-4560-84B0-61E5C8830E7D@ORACLE.COM> From: Richard Biener Date: Tue, 8 Dec 2020 08:35:04 +0100 Message-ID: Subject: Re: How to traverse all the local variables that declared in the current routine? To: Qing Zhao Cc: Richard Sandiford , Qing Zhao via Gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 07:35:18 -0000 On Mon, Dec 7, 2020 at 7:34 PM Qing Zhao wrote: > > > > On Dec 7, 2020, at 12:05 PM, Richard Sandiford wrote: > > Qing Zhao writes: > > On Dec 7, 2020, at 11:10 AM, Richard Sandiford wrote: > > > Another issue is, in order to check whether an auto-variable has initiali= zer, I plan to add a new bit in =E2=80=9Cdecl_common=E2=80=9D as: > /* In a VAR_DECL, this is DECL_IS_INITIALIZED. */ > unsigned decl_is_initialized :1; > > /* IN VAR_DECL, set when the decl is initialized at the declaration. */ > #define DECL_IS_INITIALIZED(NODE) \ > (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized) > > set this bit when setting DECL_INITIAL for the variables in FE. then keep= it > even though DECL_INITIAL might be NULLed. > > > For locals it would be more reliable to set this flag during gimplificati= on. > > Do you have any comment and suggestions? > > > As said above - do you want to cover registers as well as locals? I'd do > the actual zeroing during RTL expansion instead since otherwise you > have to figure youself whether a local is actually used (see expand_stack= _vars) > > Note that optimization will already made have use of "uninitialized" stat= e > of locals so depending on what the actual goal is here "late" may be too = late. > > > Haven't thought about this much, so it might be a daft idea, but would a > compromise be to use a const internal function: > > X1 =3D .DEFERRED_INIT (X0, INIT) > > where the X0 argument is an uninitialised value and the INIT argument > describes the initialisation pattern? So for a decl we'd have: > > X =3D .DEFERRED_INIT (X, INIT) > > and for an SSA name we'd have: > > X_2 =3D .DEFERRED_INIT (X_1(D), INIT) > > with all other uses of X_1(D) being replaced by X_2. The idea is that: > > * Having the X0 argument would keep the uninitialised use of the > variable around for the later warning passes. > > * Using a const function should still allow the UB to be deleted as dead > if X1 isn't needed. > > * Having a function in the way should stop passes from taking advantage > of direct uninitialised uses for optimisation. > > This means we won't be able to optimise based on the actual init > value at the gimple level, but that seems like a fair trade-off. > AIUI this is really a security feature or anti-UB hardening feature > (in the sense that users are more likely to see predictable behaviour > =E2=80=9Cin the field=E2=80=9D even if the program has UB). > > > The question is whether it's in line of peoples expectation that > explicitely zero-initialized code behaves differently from > implicitely zero-initialized code with respect to optimization > and secondary side-effects (late diagnostics, latent bugs, etc.). > > Introducing a new concept like .DEFERRED_INIT is much more > heavy-weight than an explicit zero initializer. > > > What exactly you mean by =E2=80=9Cheavy-weight=E2=80=9D? More difficult t= o implement or much more run-time overhead or both? Or something else? > > The major benefit of the approach of =E2=80=9C.DEFERRED_INIT=E2=80=9D is= to enable us keep the current -Wuninitialized analysis untouched and also = pass > the =E2=80=9Cuninitialized=E2=80=9D info from source code level to =E2=80= =9Cpass_expand=E2=80=9D. > > > Well, "untouched" is a bit oversimplified. You do need to handle > .DEFERRED_INIT as not > being an initialization which will definitely get interesting. > > > Yes, during uninitialized variable analysis pass, we should specially han= dle the defs with =E2=80=9C.DEFERRED_INIT=E2=80=9D, to treat them as uninit= ializations. > > > Are you sure we need to do that? The point of having the first argument > to .DEFERRED_INIT was that that argument would still provide an > uninitialised use of the variable. And the values are passed and > returned by value, so the lack of initialisation is explicit in > the gcall itself, without knowing what the target function does. > > The idea is that we can essentially treat .DEFERRED_INIT as a normal > (const) function call. I'd be surprised if many passes needed to > handle it specially. > > > Just checked with a small testing case (to emulate the .DEFERRED_INIT app= roach): > > qinzhao@gcc10:~/Bugs/auto-init$ cat t.c > extern int DEFFERED_INIT (int, int) __attribute__ ((const)); > > int foo (int n, int r) > { > int v; > > v =3D DEFFERED_INIT (v, 0); > if (n < 10) > v =3D r; > > return v; > } > qinzhao@gcc10:~/Bugs/auto-init$ sh t > /home/qinzhao/Install/latest_write/bin/gcc -O -Wuninitialized -fdump-tree= -all -S t.c > t.c: In function =E2=80=98foo=E2=80=99: > t.c:7:7: warning: =E2=80=98v=E2=80=99 is used uninitialized [-Wuninitiali= zed] > 7 | v =3D DEFFERED_INIT (v, 0); > | ^~~~~~~~~~~~~~~~~~~~ > > We can see that the current uninitialized variable analysis treats the ne= w added artificial initialization as the first use of the uninialized varia= ble. Therefore report the warning there. > However, we should report warning at =E2=80=9Creturn v=E2=80=9D. > > > Ah, OK, so this is about the quality of the warning, rather than about > whether we report a warning or not? > > So, I think that we still need to specifically handle the new added artif= icial initialization during uninitialized analysis phase. > > > Yeah, that sounds like one approach. But if we're adding .DEFERRED_INIT > in response to known uninitialised uses, two other approaches might be: > > (1) Give the call the same source location as one of the uninitialised us= es. > > (2) Pass the locations of all uninitialised uses as additional arguments. > > > If we add .DEFERRED_INIT during gimplification phase, is the =E2=80=9Cuni= nitialized uses=E2=80=9D information available at that time? No. > Qing > > > The uninit pass would then be picking the source location differently > from normal, but I don't know what effect it would have on the quality > of diagnostics. One obvious problem is that if there are multiple > uninitialised uses, some of them might get optimised away later. > On the other hand, using early source locations might give better > results in some cases. I guess it will depend. > > Thanks, > Richard > >