From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 9AE6C3847839 for ; Tue, 22 Jun 2021 19:04:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9AE6C3847839 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 imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 6D04B21954; Tue, 22 Jun 2021 19:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624388698; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtYbNWm86iuIPq0XLMt7zvBgppNXdWNkqL6Myu8H2Rw=; b=JvOpLKeYIwxCXSiEwGAtq/2BMSi5vs0gc/2bltvuwFrANOVrA0FIAIbwe8BAYrHrfayYMM 7uLAiARY0IgNmoiR+J1GwvoOlFfEouwRxCOJYHU0jjL6/OWFY1J460sqyAEI9eoz99Agti PjpCG0ym1P3YwnwQXZaV+Go09rxo09E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624388698; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtYbNWm86iuIPq0XLMt7zvBgppNXdWNkqL6Myu8H2Rw=; b=a+H0JgE0ZgabQ3ZjXBGnJbM3HJQrKir2uN+2eGtkJ0YdtnMhv/bxe9xwfbkYU4WcTeDFPV Brvi92GwmYHzLxAg== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 4C03511A97; Tue, 22 Jun 2021 19:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1624388698; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtYbNWm86iuIPq0XLMt7zvBgppNXdWNkqL6Myu8H2Rw=; b=JvOpLKeYIwxCXSiEwGAtq/2BMSi5vs0gc/2bltvuwFrANOVrA0FIAIbwe8BAYrHrfayYMM 7uLAiARY0IgNmoiR+J1GwvoOlFfEouwRxCOJYHU0jjL6/OWFY1J460sqyAEI9eoz99Agti PjpCG0ym1P3YwnwQXZaV+Go09rxo09E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1624388698; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NtYbNWm86iuIPq0XLMt7zvBgppNXdWNkqL6Myu8H2Rw=; b=a+H0JgE0ZgabQ3ZjXBGnJbM3HJQrKir2uN+2eGtkJ0YdtnMhv/bxe9xwfbkYU4WcTeDFPV Brvi92GwmYHzLxAg== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id 02zZEVo00mAGeAAALh3uQQ (envelope-from ); Tue, 22 Jun 2021 19:04:58 +0000 Date: Tue, 22 Jun 2021 21:04:56 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <34CF7698-4097-4D53-8074-FCDD5C4EA3AB@oracle.com> References: <41B59ACD-94E9-45A4-9BB5-84154FAB6DAE@oracle.com> <25A77D77-5251-46EC-8E46-2F19B8BC510A@oracle.com> <42063D5B-FD16-47A0-833C-7730B0E0B700@oracle.com> <24CC2004-E379-4988-AC38-0EAAD9892862@oracle.com> <202106181644.1AF193B2@keescook> <202106210916.DCC72C72@keescook> <98D4B1E1-FF73-415F-A168-BE13EE8A2ED5@oracle.com> <34CF7698-4097-4D53-8074-FCDD5C4EA3AB@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc To: Qing Zhao CC: Richard Sandiford , Kees Cook , gcc-patches Qing Zhao via From: Richard Biener Message-ID: <801A8F9E-67F9-4D10-832F-E4535B8BCDE7@suse.de> X-Spam-Status: No, score=-4.8 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: Tue, 22 Jun 2021 19:05:02 -0000 On June 22, 2021 4:33:09 PM GMT+02:00, Qing Zhao = wrote: > > >> On Jun 22, 2021, at 9:15 AM, Richard Biener >wrote: >>=20 >> On Tue, 22 Jun 2021, Qing Zhao wrote: >>=20 >>>=20 >>>=20 >>>> On Jun 22, 2021, at 9:00 AM, Richard Biener >wrote: >>>>=20 >>>> On Tue, 22 Jun 2021, Qing Zhao wrote: >>>>=20 >>>>> So, I am wondering why not still keep my current implementation on > >>>>> assign different patterns for different types? >>>>>=20 >>>>> This major issue with this design is the code size and runtime >overhead,=20 >>>>> but for debugging purpose, those are not that important, right? >And we=20 >>>>> can add some optimization later to improve the code size and >runtime=20 >>>>> overhead=2E >>>>>=20 >>>>> Otherwise, if we only use one pattern for all the types in this >initial=20 >>>>> version, later we still might need change it=2E >>>>>=20 >>>>> How do you think? >>>>=20 >>>> No, let's not re-open that discussion=2E As said we can look to >support >>>> multi-byte pattern if that has a chance to improve things but only >>>> as followup=2E >>>=20 >>> I am fine with this=2E >>>=20 >>> However, we need to decide whether we will use one-byte repeatable >pattern, or multiple-byte repeatable pattern now, >>> Since the implementation will be different=2E If using one-byte, the >implementation will be the simplest, we can use memset for all >>> VLA, non-vla, zero-init, or pattern-init consistently=2E >>>=20 >>> However, if we choose multiple-byte pattern, then the implementation >will be different, we cannot use memset for pattern-init, and=20 >>> The implemenation for VLA pattern-init also is different=2E >>=20 >> As said, we can do this as followup=2E For now get the easiest thing >> working - one-byte patterns via memset=2E =20 > >Okay=2E I will work on this=2E > >> There's enough bits in the >> patch that will likely need followup fixes (the =2EDEFERED_INIT stuff), > >Do you mean your previous suggestion to merge the handling of VLA to >non-VLA during gimplification phase? >I have done with this change locally=2E No, just bugs that will inevitably show up=2E=20 >> actual code gneration of the init is separate enough we can deal with >> it later=2E Also IMHO not all targets necessarily need to behave the >> same there=2E > >Then, shall we make the code generation part a target hook now? Or do >this later? Do this later, if the need arises=2E=20 Richard=2E=20 >Qing >>=20 >> Richard=2E >>=20 >>> Qing >>>>=20 >>>> Thanks, >>>> Richard=2E >>>>=20 >>>>> Qing >>>>>=20 >>>>> On Jun 22, 2021, at 3:59 AM, Richard Biener >> wrote: >>>>>=20 >>>>> On Tue, 22 Jun 2021, Richard Sandiford wrote: >>>>>=20 >>>>> Kees Cook > >writes: >>>>> On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote: >>>>> So, if =E2=80=9Cpattern value=E2=80=9D is =E2=80=9C0xFFFFFFFFFFFFFFF= F=E2=80=9D, then it=E2=80=99s a valid >canonical virtual memory address=2E However, for most OS, >=E2=80=9C0xFFFFFFFFFFFFFFFF=E2=80=9D should be not in user space=2E >>>>>=20 >>>>> My question is, is =E2=80=9C0xFFFFFFFFFFFFFFFFF=E2=80=9D good for po= inter? Or >=E2=80=9C0xAAAAAAAAAAAAAAAA=E2=80=9D better? >>>>>=20 >>>>> I think 0xFF repeating is fine for this version=2E Everything else >is a >>>>> "nice to have" for the pattern-init, IMO=2E :) >>>>>=20 >>>>> Sorry to be awkward, but 0xFF seems worse than 0xAA to me=2E >>>>>=20 >>>>> For integer types, all values are valid representations, and we're >>>>> relying on the pattern being =E2=80=9Cobviously=E2=80=9D wrong in co= ntext=2E=20 >0xAAAA=E2=80=A6 >>>>> is unlikely to be a correct integer but 0xFFFF=E2=80=A6 would instea= d be a >>>>> =E2=80=9Cnice=E2=80=9D -1=2E It would be difficult to tell in a deb= ugger that a -1 >>>>> came from pattern init rather than a deliberate choice=2E >>>>>=20 >>>>> I agree that, all other things being equal, it would be nice to >use NaNs >>>>> for floats=2E But relying on wrong numerical values for floats >doesn't >>>>> seem worse than doing that for integers=2E >>>>>=20 >>>>> 0xAA=E2=80=A6 for float is (if I've got this right) >-3=2E0316488252093987e-13, >>>>> which admittedly doesn't stand out as wrong=2E But I'm not sure we >>>>> should sacrifice integer debugging for float debugging here=2E >>>>>=20 >>>>> We can always expose the actual value as --param=2E Now, I think >>>>> we'd need a two-byte pattern to reliably produce NaNs anyway, >>>>> so with floats taken out of the picture the focus should be on >>>>> pointers where IMHO val & 1 and val & 15 would be nice to have=2E >>>>> So sth like 0xf7 would work for those=2E With a two-byte pattern >>>>> we could use 0xffef or 0x7fef=2E >>>>>=20 >>>>> Anyway, it's probably down to priorities of the project involved >>>>> (debugging FP stuff or integer stuff)=2E >>>>>=20 >>>>> Richard=2E >>>>>=20 >>>>>=20 >>>>=20 >>>> --=20 >>>> Richard Biener >>>> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 >Nuernberg, >>>> Germany; GF: Felix Imend=C3=B6rffer; HRB 36809 (AG Nuernberg) >>>=20 >>>=20 >>=20 >> --=20 >> Richard Biener >> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 >Nuernberg, >> Germany; GF: Felix Imend=C3=B6rffer; HRB 36809 (AG Nuernberg)