From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 4CCC73857012 for ; Mon, 7 Jun 2021 07:53:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4CCC73857012 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (unknown [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 64BD31FD30; Mon, 7 Jun 2021 07:53:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1623052395; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w+U78kGcsdyElZa5YyKVkOcRLlQB6a+68YIS2BEsKKo=; b=Fwd97rIVpDGaZd4yDqVfQbTWrFPWsUNXXjOs68Qz8bxheZJGuwJRBwjDltLtovXKkkB3lP 5QKqhWdJizpA/L2y+Ee4EDbgCapjzdt6c6lZDqYl8/NHsfEKd636c7woAR9lCmJm7suiwY fyFuvwA+bBNmdrJIvhkN0I5tDQTyOEM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1623052395; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w+U78kGcsdyElZa5YyKVkOcRLlQB6a+68YIS2BEsKKo=; b=yBH8NBamfQvMXtVbs0glZtICxPCJZJgZ/cRJHNLblvfxQqgHgNze5EZtWcKIg7uSj427tV L+vltABM+Brny3Cg== Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 5E47EA3B84; Mon, 7 Jun 2021 07:53:15 +0000 (UTC) Date: Mon, 7 Jun 2021 09:53:15 +0200 (CEST) From: Richard Biener To: Qing Zhao cc: richard Sandiford , kees Cook , gcc-patches Qing Zhao via Subject: Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc In-Reply-To: <720A8309-1964-4861-BE1C-7F7E1EB9FE18@oracle.com> Message-ID: References: <52959802-6AF1-4BFC-B984-3BC495C535BD@ORACLE.COM> <720A8309-1964-4861-BE1C-7F7E1EB9FE18@oracle.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Mon, 07 Jun 2021 07:53:26 -0000 On Thu, 3 Jun 2021, Qing Zhao wrote: > Hi, Richard, > > > On May 26, 2021, at 6:18 AM, Richard Biener > wrote: > > On Wed, 12 May 2021, Qing Zhao wrote: > > Hi, > > This is the 3rd version of the patch for the new security feature for GCC. > > Please take look and let me know your comments and suggestions. > > > +/* Returns true when the given TYPE has padding inside it. > + return false otherwise. */ > +bool > +type_has_padding (tree type) > +{ > + switch (TREE_CODE (type)) > + { > + case RECORD_TYPE: > + { > > btw, there's __builtin_clear_padding and a whole machinery around > it in gimple-fold.c, I'm sure that parts could be re-used if they > are neccessary in the end. > > To address the above suggestion: > > My study shows: the call to __builtin_clear_padding is expanded during gimplification phase. > And there is no __bultin_clear_padding expanding during rtx expanding phase. > However, for -ftrivial-auto-var-init, padding initialization should be done both in gimplification phase and rtx expanding phase. > since the __builtin_clear_padding might not be good for rtx expanding, reusing __builtin_clear_padding might not work. > > Let me know if you have any more comments on this. Yes, I didn't suggest to literally emit calls to __builtin_clear_padding but instead to leverage the lowering code, more specifically share the code that figures _what_ is to be initialized (where the padding is) and eventually the actual code generation pieces. That might need some refactoring but the code where padding resides should be present only a single time (since it's quite complex). Which is also why I suggested to split out the padding initialization bits to a separate patch (and option). Richard.