From patchwork Thu Nov 8 15:19:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 994955 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-489401-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="SPgLeYdZ"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 42rRmF0V9Xz9sBN for ; Fri, 9 Nov 2018 02:19:54 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=h/JoDIU4+H6rBMA3 xFwlkHxLjmZvnu8uAjcjDLB6KSIUT82R38Yucx8ZozDcC4IYNPiMbC+AXED1nWUR xrzcilwKvfTru0TDMaCMf3AzTW/GkipS39I332LlX6XeocG9KFahA1lEaFWqTZDr 4v/XCaxskGhUHxxeOdYdjsKUmK8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=l4onxA3N2IRSJomNXfzqhC wNwv0=; b=SPgLeYdZNF2os1247rEa+P5VVCm1xQPszAsgacFjX0vYdUbJUCUmH/ gYIQwlqL9QmQ2GY+ly/XVKFOiBDYJki4VDW61BGPWlG6DPrr7J5ImKE5BBYOPqpe qoz0LsKvrj4yezmZRbPG8yZQ7vw016Nd2ayc+uGhBGy86vn2EIklc= Received: (qmail 20345 invoked by alias); 8 Nov 2018 15:19:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 20334 invoked by uid 89); 8 Nov 2018 15:19:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=gcc-interface, gccinterface X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Nov 2018 15:19:45 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 45811818CC for ; Thu, 8 Nov 2018 16:19:43 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkNp59E7ITyD for ; Thu, 8 Nov 2018 16:19:43 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 1925D812E5 for ; Thu, 8 Nov 2018 16:19:43 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [Ada] Disable DECL_BIT_FIELD_REPRESENTATIVE machinery in some cases Date: Thu, 08 Nov 2018 16:19:41 +0100 Message-ID: <8567951.N08qWEOn1i@polaris> MIME-Version: 1.0 We can have quite convoluted layouts in Ada when a representation clause is given for a record type with variant part and this doesn't always play nice with the DECL_BIT_FIELD_REPRESENTATIVE machinery. This patch arranges for DECL_BIT_FIELD_TYPE to be cleared on the variant part in these cases. Tested on x86_64-suse-linux, applied on the mainline. 2018-11-08 Eric Botcazou * gcc-interface/decl.c (components_to_record): Remove obsolete kludge. * gcc-interface/utils.c (make_packable_type): Set TYPE_PACKED on the new type but do not take into account the setting on the old type for the new fields. Rename a local variable. (finish_record_type): Clear DECL_BIT_FIELD_TYPE on a variant part at offset 0, if any. (create_field_decl): Tweak comment. Index: gcc-interface/decl.c =================================================================== --- gcc-interface/decl.c (revision 265866) +++ gcc-interface/decl.c (working copy) @@ -8146,23 +8146,7 @@ components_to_record (Node_Id gnat_compo /* Chain the variant part at the end of the field list. */ if (gnu_variant_part) - { - /* We make an exception if the variant part is at offset 0, has a fixed - size, and there is a single rep'ed field placed after it because, in - this case, there is an obvious order of increasing position. */ - if (variants_have_rep - && TREE_CODE (DECL_SIZE_UNIT (gnu_variant_part)) == INTEGER_CST - && gnu_rep_list - && gnu_field_list == gnu_rep_list - && !tree_int_cst_lt (DECL_FIELD_OFFSET (gnu_rep_list), - DECL_SIZE_UNIT (gnu_variant_part))) - { - DECL_CHAIN (gnu_variant_part) = gnu_field_list; - gnu_field_list = gnu_variant_part; - } - else - gnu_field_list = chainon (gnu_field_list, gnu_variant_part); - } + gnu_field_list = chainon (gnu_field_list, gnu_variant_part); if (cancel_alignment) SET_TYPE_ALIGN (gnu_record_type, 0); Index: gcc-interface/utils.c =================================================================== --- gcc-interface/utils.c (revision 265866) +++ gcc-interface/utils.c (working copy) @@ -973,6 +973,7 @@ make_packable_type (tree type, bool in_r Note that we rely on the pointer equality created here for TYPE_NAME to look through conversions in various places. */ TYPE_NAME (new_type) = TYPE_NAME (type); + TYPE_PACKED (new_type) = 1; TYPE_JUSTIFIED_MODULAR_P (new_type) = TYPE_JUSTIFIED_MODULAR_P (type); TYPE_CONTAINS_TEMPLATE_P (new_type) = TYPE_CONTAINS_TEMPLATE_P (type); TYPE_REVERSE_STORAGE_ORDER (new_type) = TYPE_REVERSE_STORAGE_ORDER (type); @@ -1018,7 +1019,7 @@ make_packable_type (tree type, bool in_r for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field)) { tree new_field_type = TREE_TYPE (field); - tree new_field, new_size; + tree new_field, new_field_size; if (RECORD_OR_UNION_TYPE_P (new_field_type) && !TYPE_FAT_POINTER_P (new_field_type) @@ -1034,14 +1035,15 @@ make_packable_type (tree type, bool in_r && !TYPE_FAT_POINTER_P (new_field_type) && !TYPE_CONTAINS_TEMPLATE_P (new_field_type) && TYPE_ADA_SIZE (new_field_type)) - new_size = TYPE_ADA_SIZE (new_field_type); + new_field_size = TYPE_ADA_SIZE (new_field_type); else - new_size = DECL_SIZE (field); + new_field_size = DECL_SIZE (field); + /* This is a layout with full representation, alignment and size clauses + so we simply pass 0 as PACKED like gnat_to_gnu_field in this case. */ new_field = create_field_decl (DECL_NAME (field), new_field_type, new_type, - new_size, bit_position (field), - TYPE_PACKED (type), + new_field_size, bit_position (field), 0, !DECL_NONADDRESSABLE_P (field)); DECL_INTERNAL_P (new_field) = DECL_INTERNAL_P (field); @@ -1896,6 +1898,14 @@ finish_record_type (tree record_type, tr DECL_BIT_FIELD (field) = 0; } + /* Clear DECL_BIT_FIELD_TYPE for a variant part at offset 0, it's simply + not supported by the DECL_BIT_FIELD_REPRESENTATIVE machinery because + the variant part is always the last field in the list. */ + if (DECL_INTERNAL_P (field) + && TREE_CODE (TREE_TYPE (field)) == QUAL_UNION_TYPE + && integer_zerop (pos)) + DECL_BIT_FIELD_TYPE (field) = NULL_TREE; + /* If we still have DECL_BIT_FIELD set at this point, we know that the field is technically not addressable. Except that it can actually be addressed if it is BLKmode and happens to be properly aligned. */ @@ -2725,9 +2735,9 @@ create_field_decl (tree name, tree type, size = round_up (size, BITS_PER_UNIT); } - /* If we may, according to ADDRESSABLE, make a bitfield if a size is + /* If we may, according to ADDRESSABLE, make a bitfield when the size is specified for two reasons: first if the size differs from the natural - size. Second, if the alignment is insufficient. There are a number of + size; second, if the alignment is insufficient. There are a number of ways the latter can be true. We never make a bitfield if the type of the field has a nonconstant size, @@ -2735,7 +2745,7 @@ create_field_decl (tree name, tree type, We do *preventively* make a bitfield when there might be the need for it but we don't have all the necessary information to decide, as is the case - of a field with no specified position in a packed record. + of a field in a packed record. We also don't look at STRICT_ALIGNMENT here, and rely on later processing in layout_decl or finish_record_type to clear the bit_field indication if