From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by sourceware.org (Postfix) with ESMTPS id 4212A3858C3A for ; Sat, 24 Jun 2023 02:39:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4212A3858C3A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3a1ba074dadso77957b6e.1 for ; Fri, 23 Jun 2023 19:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1687574340; x=1690166340; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:errors-to:references:organization:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=Bo5l7XwAeweqGl/foOBTS0JRyVyj6phuDejIwdL1mNA=; b=duJvHUJLotZ8eOwQfm1g4nnP9Wl/5BIgFNPAXWdVpy7bf+G3/YPQxaKhfGwyKf/O3v azTBT15gi7OexQo3Ll4PuyMuYGVuqtNvmPeVd2itqr1yScLtog5BxSzQQtrsF2ex0zI5 sMjT8F4KR+TvOVTGfI5OrZ2lmspp/QM+5f8/S3tvT5LxG9pwCUmvqyGaqapsP1oNO5V5 dyeY+FpfSkV9yqkjoB4M4uKTQ4HbwO0gqt/Zg3G9ei6AvnKBE5EQYwKHhOmPG6BCkqHr o64rLnzYJLM6oG40yraLd5NQxv9t3YzjcJhi2popb/Ijvt2wtSvJLmbEmXJjkKzNNL8k rUSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687574340; x=1690166340; h=content-transfer-encoding:mime-version:user-agent:message-id :in-reply-to:date:errors-to:references:organization:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Bo5l7XwAeweqGl/foOBTS0JRyVyj6phuDejIwdL1mNA=; b=CPGyEVbhPttEtIGtmBYqe/JVEBsdHlQI27Gkea/NCdTKRZVT4exslEgANoauMgZ5th 4eMCwnGlrupMcPsuv7/Vo4QXx4AxalMwkts9xzJMAQU1HLJDvPEyscESJlNsZSwYVZlv Z/q+9CFlVoKzPA2G7tnQNPsCbMdBye/i4Ctb/PQBfNn/Q3nhSLtoHlrtzKWZz5xzOljV F20j+EVj95tn2YP5YrIAtVcC4qHgcKIQUNJR1iKFviGldr05nz7mFGTD74z3u0cjSzJ+ bezkTUMtBxEM8eH+KcftmCxWAKlMERxYefCjkRCDqK+eC9OtLDYJEz8xRgKfpHXctQK/ uS4Q== X-Gm-Message-State: AC+VfDxTqGy3q7MKW7ZJCU4Shs3YJjmlQTz5au8at9bOg/2pfQbSJrWR ENUMum0sJLOha5jGs4d3UBuhJ9e+e+HN7KaZco0= X-Google-Smtp-Source: ACHHUZ61OMOTMRn8evQsYFBYXU6TwIiB/bSsA4wP9t2tIeQrDACthqmRmhM4BuMMqW5RhlGlN3IYKQ== X-Received: by 2002:a05:6808:f12:b0:399:169:75d4 with SMTP id m18-20020a0568080f1200b00399016975d4mr25133632oiw.36.1687574340270; Fri, 23 Jun 2023 19:39:00 -0700 (PDT) Received: from free.home ([2804:7f1:2080:5f5c:a5d4:5604:3034:12b5]) by smtp.gmail.com with ESMTPSA id w14-20020a0568080d4e00b003a1b67c5529sm306445oik.3.2023.06.23.19.38.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jun 2023 19:38:59 -0700 (PDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 35O2chGs885134 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 23 Jun 2023 23:38:44 -0300 From: Alexandre Oliva To: Qing Zhao via Gcc-patches Cc: Qing Zhao , Joseph Myers Subject: Re: [PATCH] Introduce hardbool attribute for C Organization: Free thinker, does not speak for AdaCore References: Errors-To: aoliva@lxoliva.fsfla.org Date: Fri, 23 Jun 2023 23:38:43 -0300 In-Reply-To: (Qing Zhao via Gcc-patches's message of "Fri, 23 Jun 2023 21:40:37 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Jun 23, 2023, Qing Zhao via Gcc-patches wrote: > -ftrivial-auto-var-init has been in GCC since GCC12.=20=20 *nod*. IIRC I started designing hardbool in GCC10, but the first complete implementation was for GCC11. > The decision to use 0x00 for zero-initiation, 0xfe for pattern-initiation > has been discussed thoroughly during the design phase. -:) *nod*, and it's a good one > Since this hardbool attribute will also be a security feature, users tha= t seek > security features of GCC will likely ask the same question for these two > features. > So, their interaction is better to be at least documented. That=E2=80=99s= my main point. *nod*. At first, I thought the ideal place to clarify the issue was in the documentation for the option, because there's nothing exceptional about the option's behavior when it comes to hardbool specifically. But it doesn't hurt to mention it in both places, so I did. How about the incremental patchlet below (at the end)? > For normal Boolean variables, 0x00 is false, this is a reasonable init > value with zero-initialization. *nod*. I was surprised by zero initialization of (non-hardened) booleans even when pattern is requested, but not consistently (e.g. boolean fields of a larger struct would still get pattern-initialized IIUC). I'd have expected pattern would translate to nonzero and thus to true, rather than false. > For hardbool variables, what 0x00 represents if it=E2=80=99s not false or= true > value? It depends on how hardbool is parameterized. One may pick 0x00 or 0xFE as the representations for true or false, or neither, in which case the trivial initializer will end up as a trapping value. >> I'd probably have arranged for the front-end to create the initializer >> value, because expansion time is too late to figure it out: we may not >> even have the front-end at hand any more, in case of lto compilation. > Is the hardbool attribute information available during the rtl expansion = phase? It is in the sense that the attribute lives on, but c_hardbool_type_attr is a frontend function, it cannot be called from e.g. lto1. The hardbool attribute is also implemented in Ada, but there it only affects validity checking in the front end: Boolean types in Ada are Enumeration types, and there is standard syntax to specify the representations for true and false. AFAICT, once we translate GNAT IR to GNU IR, hardened booleans would not be recognizable as boolean types. Even non-hardened booleans with representation clauses would. So handling these differently from other enumeration types, to make them closer to booleans, would be a bit of a challenge, and a backwards-compatibility issue (because such booleans have already been handled in the present way since the introduction of -ftrivial-* back in GCC12) >> Now, I acknowledge that the decision to make implicit >> zero-initialization of boolean types set them to the value for false, >> rather than to all-bits-zero representation, is a departure from common >> practice of zero-initialization yielding logical zero. > Dont=E2=80=99s quite understand the above, for normal boolean variables, Sorry, I meant hardened boolean types. This was WRT to the design decision that led to this bit in the documentation: typedef char __attribute__ ((__hardbool__ (0x5a))) hbool; [...] static hbool zeroinit; /* False, stored as (char)0x5a. */ auto hbool uninit; /* Undefined, may trap. */ =20=20 > And this is a very reasonable initial value for Boolean variables, Agreed. The all-zeros bit pattern is not so great for booleans that use alternate representations, though, such as the following standard Ada: type MyBool is new Boolean; for MyBool use (16#5a#, 16#a5#); for MyBool'Size use 8; or for biased variables such as: X : Integer range 254 .. 507; for X'Size use 8; -- bits, so a biased representation is required. Just to make things more interesting, I chose a range for X that causes the compiler to represent 0xfe as 0x00 in in the byte that holds X, but that places the 0xfe pattern just out of the range :-) So with -ftrivial-auto-var-init=3Dzero, X =3D 254, whereas with -ftrivial-auto-var-init=3Dpattern, it fails validity checking, and might come out as 508 if that's disabled. > From my understanding, only with the introduction of =E2=80=9Chardbool=E2= =80=9D > attribute, all-bits-zero will not be equal to the > logical false anymore.=20 Ada booleans have long allowed nonzero representations for false. diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 772209c1793e8..ae7867bb35696 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -8774,6 +8774,12 @@ on the bits held in the storage (re)used for the var= iable, if any, and on optimizations the compiler may perform on the grounds that using uninitialized values invokes undefined behavior. =20 +Users of @option{-ftrivial-auto-var-init} should be aware that the bit +patterns used as its trivial initializers are @emph{not} converted to +@code{hardbool} types, so using variables implicitly initialized by it +may trap if the representations values chosen for @code{false} and +@code{true} do not match the initializer. + =20 @cindex @code{may_alias} type attribute @item may_alias diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 296a9c178b195..e21f468a9c8f3 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13510,6 +13510,23 @@ The values used for pattern initialization might b= e changed in the future. =20 The default is @samp{uninitialized}. =20 +Note that the initializer values, whether @samp{zero} or @samp{pattern}, +refer to data representation (in memory or machine registers), rather +than to their interpretation as numerical values. This distinction may +be important in languages that support types with biases or implicit +multipliers, and with such extensions as @samp{hardbool} (@pxref{Type +Attributes}). For example, a variable that uses 8 bits to represent +(biased) quantities in the @code{range 160..400} will be initialized +with the bit patterns @code{0x00} or @code{0xFE}, depending on +@var{choice}, whether or not these representations stand for values in +that range, and even if they do, the interpretation of the value held by +the variable will depend on the bias. A @samp{hardbool} variable that +uses say @code{0X5A} and @code{0xA5} for @code{false} and @code{true}, +respectively, will trap with either @samp{choice} of trivial +initializer, i.e., @samp{zero} initialization will not convert to the +representation for @code{false}, even if it would for a @code{static} +variable of the same type. + You can control this behavior for a specific variable by using the variable attribute @code{uninitialized} (@pxref{Variable Attributes}). =20 --=20 Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about