From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c]) by sourceware.org (Postfix) with ESMTPS id 150F53858D1E for ; Wed, 28 Jun 2023 07:26:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 150F53858D1E 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-oa1-x2c.google.com with SMTP id 586e51a60fabf-1b0419f758eso459140fac.1 for ; Wed, 28 Jun 2023 00:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1687937185; x=1690529185; 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=EJKlOGXxOsaobKj8mI/hwAqPCtfQN4iR9ah6fh0q7Lw=; b=gGN8b4VSJ48B3xX8POWFvJ7zxTUs3ayWRja+2mu7ZICINJYKEXN8G+TBTkkrYhVCWw 5MQ4pmK+vYvhYobmCk6Z9AKAmmA2LiubgdnhLFV6526D3guspRW8CxnzmWPTtXXynLM1 A997cuJGOsgdegM1HRN67c5/H9Zu+HpX+wASB9bxOGOK++B4AQUEcL5ep+DUvRAghAJM 4KsUqOJVmQ0gPYHWjMss2zPaIJZ0HaYpLbUTiAjZVPnEiDJmW5VMPsKcjohAGtDSYl9Y iqnQNkY4J4kZflSEaeVHFTTva184YAVexlTxkipKn8ACnrWynO7/+E2oVIlvG508RTrB fa2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687937185; x=1690529185; 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=EJKlOGXxOsaobKj8mI/hwAqPCtfQN4iR9ah6fh0q7Lw=; b=erQYIiVzoy3lCW7kdmDBAg/my4IqOhKzzg7fcQrQVnErReDeGtfTJlYKr8R0aNg6r2 S1bCzMXAHdo6muVG4sRzmm7ZmIgebo7eZq+zWSdP1/MF1L2q3+aekI0wwQN8wSLzXCBZ BwQFIZSRf+9Fz6/WJDeUBsoOpLAqToXleXzGgGbr4GDvlpdCBK5XugJZX1cLvsT9rlVY ytEnhHqBatr6KkZV5hiFZSPT3wKU6KLW8n3yzMivdlQXPV+zda/a9CZL19ZqR57wXp0a Ab1Ky45EU4a9e8nMB5/+dSWKXBH8OKF74bud88nxXslJ5APz+GYhhQJcwocbenmlTXui Xexw== X-Gm-Message-State: AC+VfDy4mWmPNH6KgPtBvJhASiWnEQe9IWxFhH2g+QbUT1qam8BYcqEi 1TW3wr1L5NfVpS3Kc8te9y1sPg== X-Google-Smtp-Source: ACHHUZ636kVOGuOswGSCHV0hVLJy5VVc2o87wJJCwlsH1/pZOiyaPKpOuVlk1DWYd1980Ou8pw4I+A== X-Received: by 2002:a05:6870:42cc:b0:1a6:8911:61a9 with SMTP id z12-20020a05687042cc00b001a6891161a9mr422981oah.29.1687937185027; Wed, 28 Jun 2023 00:26:25 -0700 (PDT) Received: from free.home ([2804:7f1:2080:5f5c:a5d4:5604:3034:12b5]) by smtp.gmail.com with ESMTPSA id x11-20020a9d6d8b000000b006b72660f276sm4375597otp.75.2023.06.28.00.26.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jun 2023 00:26:24 -0700 (PDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 35S7QBWr1047784 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 28 Jun 2023 04:26:11 -0300 From: Alexandre Oliva To: Qing Zhao Cc: Qing Zhao via Gcc-patches , Joseph Myers Subject: Re: [PATCH] Introduce hardbool attribute for C Organization: Free thinker, does not speak for AdaCore References: <6BED3980-B5DF-4605-A6FA-390B241AB37A@oracle.com> Errors-To: aoliva@lxoliva.fsfla.org Date: Wed, 28 Jun 2023 04:26:11 -0300 In-Reply-To: <6BED3980-B5DF-4605-A6FA-390B241AB37A@oracle.com> (Qing Zhao's message of "Mon, 26 Jun 2023 19:05:42 +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=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 26, 2023, Qing Zhao wrote: >>> For hardbool variables, what 0x00 represents if it=E2=80=99s not false = or true >>> value? >>=20 >> 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. > Okay, then, this looks like a good behavior (trapping with > -ftrival-auto-var-init most of the time, > i.e, when neither 0x00 or 0xFE was chosen as the representations for tru= e or false),=20 > it will urge the user to fix the uninitialized hardbool variables. Agreed >>>> 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. >>=20 >>> Is the hardbool attribute information available during the rtl expansio= n phase? >>=20 >> 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. > does lookup_attribute work for this attribute during rtl expansion? > (Still a little confusing here) Yes, the hardbool attribute would be there in C. But not in Ada. And that should be fine, because Ada hardbool is handled entirely in the frontend, as are non-hardened booleans with representation clauses, that become enumeration types without any distinguishing feature. >> 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, right now, the GNU IR represents Ada=E2=80=99s boolean type as enumer= ation type?=20 All Ada boolean types are defined by the language as enumeration types: There is a predefined enumeration type named Boolean, [declared in the visible part of package Standard]. It has the two enumeration literals False and True ordered with the relation False < True. Any descendant of the predefined type Boolean is called a boolean type. However, boolean types without representation clauses are mapped to the language-independent boolean_type_node. Those that do are mapped to enumeration types. >> So >> handling these differently from other enumeration types, to make them >> closer to booleans, would be a bit of a challenge, > is there any special handling in GNU IR when representing Ada=E2=80=99s > boolean type as enumeration type? > Any issue right now? Not that I'm aware of. The front end takes care of converting between non-boolean_type_node enumeration types and boolean_type_node as needed, so that the GNU IR needs no extra information. >> and a >> backwards-compatibility issue (because such booleans have already been >> handled in the present way since the introduction of -ftrivial-* back in >> GCC12) > With the new hardbool attribute added for C, an original bool type > becomes an enumeration type logically, There's no change to the original bool type. Only hardbool types are represented as enumeration types in C. In Ada, boolean types with representation clauses are still represented as enumeration types, whether or not they're hardbool. > But such information is not passed to middle end through GNU IR, So, > in GCC middle-end, We still treat such type as boolean, not an > enumeration type. The middle-end doesn't know (and ATM cannot know) that those represented as enumeration types are conceptually booleans, so they are treated as enumeration types, not as booleans. >> static hbool zeroinit; /* False, stored as (char)0x5a. */ >> auto hbool uninit; /* Undefined, may trap. */ > For the hardbool variable "uninit", -ftrivial-auto-var-init=3Dzero will > initialize it to zero, and it will trap during runtime. > And at the same time, -ftrivial-auto-var-init=3Dpattern will initialize > it to 0xfe, and it will trap during runtime, too. > I think these are good behaviors, just need to be documented.=20 You mean more than what's in the patch posted last week? >>=20 >>> And this is a very reasonable initial value for Boolean variables, >>=20 >> Agreed. The all-zeros bit pattern is not so great for booleans that use >> alternate representations, though, such as the following standard Ada: >>=20 >> type MyBool is new Boolean; >> for MyBool use (16#5a#, 16#a5#); >> for MyBool'Size use 8; >>=20 >> or for biased variables such as: >>=20 >> X : Integer range 254 .. 507; >> for X'Size use 8; -- bits, so a biased representation is required. >>=20 >> 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. > for the biased variable X, it was initialized to 254 (the smallest > valid value in the range) when -ftrivial-auto-var-init=3Dzero, and > fails validity checking when -ftrivial-auto-var-init=3Dpattern, both are > GOOD and reasonable behaviors with -ftrivial-auto-var-init. *nod*. However, I don't think this specific biased representation is mandated by the language (AFAICT it doesn't even mandate support for biased representations, but it explicitly allows them). This means it could conceivably map the all-zeros pattern to a trapping value, and 0xfe could stand for 507, or 506, or even other values, depending on the bias. > How about the following: >> +Users of the @option{-ftrivial-auto-var-init} should be aware that the = bit >> +patterns used as initializers are @emph{not} converted to >> +@code{hardbool} types, so using a @code{hardbool} variable that is >> implicitly initialized >> +by the @option{-ftrivial-auto-var-init} may trap if the representation= s values >> +chosen for @code{false} and @code{true} do not match the initializer. That works for me. >> even if it would for a @code{static} >> +variable of the same type. > A little confused about the above sentence: do you mean, if a hardbool > variable is static (not auto), then the implicit initizlation to it by > the compiler will be false? (Because static variable initialization is > done by the FE) Yes, exactly, that's what's implemented and documented with the example "static hbool zeroinit" above. > But when a hardbool variable is auto, then the implicit initialization > to it by the compiler (with -ftrivial-auto-var-init) will not be > false? Yeah, it can't be counted on being false. It can be a malformed value. This is also the case of e.g. Integer ranges: X : Integer range 17..42; type E is (Red, Green, Blue); for E use (16#00f#, 16#0f0#, 16#f00#);=20=20 Y : E; -ftrivial-auto-var-init will initialize X and Y with values that are not acceptable for those variables. And, as you say, that's a good thing. --=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