From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) by sourceware.org (Postfix) with ESMTPS id D19C83858D28 for ; Thu, 22 Jun 2023 02:35:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D19C83858D28 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-oo1-xc33.google.com with SMTP id 006d021491bc7-5607b8c33ddso2546614eaf.0 for ; Wed, 21 Jun 2023 19:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1687401356; x=1689993356; 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=JntclkzSdWXk2D41Oz/oy55iYh/pEH886vZjauVk26I=; b=YtDNEXce1/uZvnYB3idHKCeATMHlkL3TW6cAPm8qkWVsC+Fdx4x7qpeMC2e2n/BLpo 5kHwk+h5uPJFVvWLYYB1IItRL1Qieh9lMUQHlPFu1Hpk/r9WZKoxuJAkNmSmTL0GRun5 Ux3pTGyfxdtU5GxY1g6+/0YSlLnO8fkJTl9KqRqH5/m2X0EN2yxAvjp4vjWzGLNJUWnm m+uj02y9riVVdlq9Mlk7nhDEhrzBg2JNw4Wn0cgawi2FmcgGUtG9Rya3NI7V7AFGzWO4 JFyPO/1lC800DZUiJcHW2CY4EjZGZJMvM4C332Ta9AJuaRdXrbTcgu+WVDZVCaxZBaqq 7V+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687401356; x=1689993356; 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=JntclkzSdWXk2D41Oz/oy55iYh/pEH886vZjauVk26I=; b=iJPwn5FT2aaeuzchEnAUPEAS9dQRzdyqoLGxCIXKQLatwd5VvQ9VO/+dX0hlqXqcyr DxAaL0jnV+3/2Zp3howQg4lOTtdgV0KtROoozuG3FnQ6cRg6bFJD/5KX7qVqNdsr7lSV qKCa7acoV9UyUYkFaY7Z0he0qrvIr2AGa3G7g98G1ByqBKbXke4s6W17XnxDWjy0dWXa /Iv0SoL/ataReiasX4Pffu90G0VkcDGGDkp42CBxy1qdVyWic/nfIk6nO4+7rRHdol4n DLbaqT+Bi2kzNCmxDY0brl2dn0AKEYfynmmgTSWc7QvF/hKRTfR0xHauNpQvzIVz9Zuo Cwhw== X-Gm-Message-State: AC+VfDyBca3RQmGxsPswLN1A0y9bdBJfGhX/e9SP5nY4JlhmGaRZHNIb JZbCdK8nbzfJzM/IIvGmMxDeGQ== X-Google-Smtp-Source: ACHHUZ7rPMlveWRwX5Gin2hjcZRW9w0SrUDcGP51xinZX4/E6c68poK/kV8eyagjD1DKvg7tJaklcA== X-Received: by 2002:a4a:d151:0:b0:55e:9ee:2a30 with SMTP id o17-20020a4ad151000000b0055e09ee2a30mr8960841oor.4.1687401356575; Wed, 21 Jun 2023 19:35:56 -0700 (PDT) Received: from free.home ([2804:7f1:2080:2a97:1921:3495:99b3:9c74]) by smtp.gmail.com with ESMTPSA id r198-20020a4a37cf000000b00560cc60d58esm228536oor.21.2023.06.21.19.35.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jun 2023 19:35:56 -0700 (PDT) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 35M2ZiEC785371 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 21 Jun 2023 23:35:45 -0300 From: Alexandre Oliva To: Qing Zhao Cc: "gcc-patches@gcc.gnu.org" , 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: Wed, 21 Jun 2023 23:35:44 -0300 In-Reply-To: (Qing Zhao's message of "Wed, 21 Jun 2023 15:57:19 +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=-4.9 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 21, 2023, Qing Zhao wrote: > I see that you have testing case to check the above built_in_trap call > is generated by FE. > Do you have a testing case to check the trap is happening at runtime?=20 I have written such tests, using type-punning, but I don't think our testing infrastructure could take trapping as success and other results as failure. > So, when -ftrivial-auto-var-init presents, what=E2=80=99s the behavior fo= r the > hardened Boolean auto variables? Good question. This option was not even available when hardbool was designed and implemented. (tests) The deferred_init internal function initializes with bit-patterns 0x00 or 0xfe, regardless of type, when the data lives in memory, and otherwise forces the 0x00 bit pattern for booleans, variable-sized types, types that cannot be accessed with a single mode or for modes that don't have a set pattern. It's hard for me to tell what "correct" or "expected" would be here. Enumerators don't seem to be given special treatment. Checked enumerators, constrained integral subtypes, none of these would get well-formed values or even checking at the assignments. If I were to design this option myself, I'd probably arrange for it to handle booleans (including hardened booleans) by zero-initializing as false and pattern-initializing as true, though I realize that this could be very confusing if one chose to use 0xfe as the value for false and/or 0x00 as the value for true. 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. But with the current description and implementation, I guess the behavior is correct, if not ideal: the bit patterns refer to the representation, rather than to the language interpretation of the value. When it comes ot integral types, they may match, but floating-point, fixed fractional types, offsets and multipliers, even boolean member of larger structs... not so much: the effect is that of a memset, rather than that of an assignment of zero or of the pattern to a variable. 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. That was unusual enough that I thought it worth mentioning in the docs. > This might need to be documented and also handled correctly.=20 I suppose the place to document this distinction between logical values and representation would be under -ftrivial-auto-var-init. That's likely where someone using that option would look for guidance on how it interacts with unusual types, and where exceptions to general expectations WRT initialization would go. Do you concur? That said, it probalby makes sense to refer to / mention that -ftrivial-auto-var-init does not special-case hardened booleans in the hardened booleans documentation. I wonder if there are other conflicting options I'm not even aware of. --=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