From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 184FD3857835 for ; Fri, 18 Jun 2021 08:30:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 184FD3857835 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-511-zHTd7X-POHSBjaDdLis1aw-1; Fri, 18 Jun 2021 04:30:08 -0400 X-MC-Unique: zHTd7X-POHSBjaDdLis1aw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3835D8042A8; Fri, 18 Jun 2021 08:30:06 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-115-161.ams2.redhat.com [10.36.115.161]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 80F386EF4F; Fri, 18 Jun 2021 08:30:05 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 15I8U3AT2580358 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 18 Jun 2021 10:30:03 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 15I8U1s42580357; Fri, 18 Jun 2021 10:30:01 +0200 Date: Fri, 18 Jun 2021 10:30:01 +0200 From: Jakub Jelinek To: Richard Biener , Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] stor-layout: Don't create DECL_BIT_FIELD_REPRESENTATIVE for QUAL_UNION_TYPE [PR101062] Message-ID: <20210618083001.GL7746@tucnak> Reply-To: Jakub Jelinek References: <20210616074517.GW7746@tucnak> MIME-Version: 1.0 In-Reply-To: <20210616074517.GW7746@tucnak> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Fri, 18 Jun 2021 08:30:14 -0000 On Wed, Jun 16, 2021 at 09:45:17AM +0200, Jakub Jelinek via Gcc-patches wrote: > The following patch does create them, but treats all such bitfields as if > they were in a structure where the particular bitfield is the only field. While the patch passed bootstrap/regtest on the trunk, when trying to backport it to 11 branch the bootstrap failed with atree.ads:3844:34: size for "Node_Record" too small errors. Turns out the error is not about size being too small, but actually about size being non-constant, and comes from: /* In a FIELD_DECL of a RECORD_TYPE, this is a pointer to the storage representative FIELD_DECL. */ #define DECL_BIT_FIELD_REPRESENTATIVE(NODE) \ (FIELD_DECL_CHECK (NODE)->field_decl.qualifier) /* For a FIELD_DECL in a QUAL_UNION_TYPE, records the expression, which if nonzero, indicates that the field occupies the type. */ #define DECL_QUALIFIER(NODE) (FIELD_DECL_CHECK (NODE)->field_decl.qualifier) so by setting up DECL_BIT_FIELD_REPRESENTATIVE in QUAL_UNION_TYPE we actually set or modify DECL_QUALIFIER and then construct size as COND_EXPRs with those bit field representatives (e.g. with array type) as conditions which doesn't fold into constant. The following patch fixes it by not creating DECL_BIT_FIELD_REPRESENTATIVEs for QUAL_UNION_TYPE as there is nowhere to store them, Bootstrapped/regtested on x86_64-linux and i686-linux (both trunk and 11 branch - there on top of the earlier patch backport). Ok for trunk and the backport? Shall we change tree.h to document that DECL_BIT_FIELD_REPRESENTATIVE is valid also on UNION_TYPE? I see: tree-ssa-alias.c- if (TREE_CODE (type1) == RECORD_TYPE tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field1)) tree-ssa-alias.c: field1 = DECL_BIT_FIELD_REPRESENTATIVE (field1); tree-ssa-alias.c- if (TREE_CODE (type2) == RECORD_TYPE tree-ssa-alias.c: && DECL_BIT_FIELD_REPRESENTATIVE (field2)) tree-ssa-alias.c: field2 = DECL_BIT_FIELD_REPRESENTATIVE (field2); Shall we change that to || == UNION_TYPE or do we assume all fields are overlapping in a UNION_TYPE already? At other spots (asan, ubsan, expr.c) it is unclear what will happen if they see a QUAL_UNION_TYPE with a DECL_QUALIFIER (or does the Ada FE lower that somehow)? 2021-06-18 Jakub Jelinek PR middle-end/101062 * stor-layout.c (finish_bitfield_layout): Don't add bitfield representatives in QUAL_UNION_TYPE. --- gcc/stor-layout.c.jj 2021-06-16 12:17:49.254221954 +0200 +++ gcc/stor-layout.c 2021-06-17 11:36:13.011822974 +0200 @@ -2172,6 +2172,9 @@ finish_bitfield_layout (tree t) tree field, prev; tree repr = NULL_TREE; + if (TREE_CODE (t) == QUAL_UNION_TYPE) + return; + for (prev = NULL_TREE, field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field)) { Jakub