From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22654 invoked by alias); 22 Aug 2017 10:57:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22638 invoked by uid 89); 22 Aug 2017 10:57:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=UNION, gun, laying, smoking X-HELO: mail-wr0-f180.google.com Received: from mail-wr0-f180.google.com (HELO mail-wr0-f180.google.com) (209.85.128.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Aug 2017 10:57:33 +0000 Received: by mail-wr0-f180.google.com with SMTP id z91so120055060wrc.4 for ; Tue, 22 Aug 2017 03:57:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tWfdXp3InfDe9UaW5doL6SOSAMIkZKQ7O6VK9CmvGao=; b=l1eeUmxIiAbI+9HtTFHTZ5cGdaghciPIGqq6B34U9tjK9W0TGINCz6yYkTeGTqwRVG FiTltWMMEE63hi7Uxg+WBTqJVBXr9jVQZFupv2FFqVO8EELT/d8N8hogH+msBHvb+tVI 8ZCZENtiE54T+wWVtrDjlpARLp/18VfyPbOg/dEUV8tSbms5pzzjAlXM5KVPEwR4KYOG uONyzp1Ec4xTeyHgkN4n+TfLeJjsp2ZCywQu6Y3DZAM+5yEM4q3xQEvG6CFT8tvB6PBa osWDBCjvJ0vMs987CO9VZtW6yau+GRPHD75i8CSWIDUzDWGoC/5ha4zfIMWFT2FOTRDk VWMw== X-Gm-Message-State: AHYfb5gthZIya/f/iN5qUzh92rdT92r2gEBBDQH02AS85qzy+8/pSYUh J3ePUeCFNbkEECbaL/xDjQ== X-Received: by 10.223.142.42 with SMTP id n39mr206945wrb.51.1503399449825; Tue, 22 Aug 2017 03:57:29 -0700 (PDT) Received: from [192.168.1.157] (81-178-167-45.dsl.pipex.com. [81.178.167.45]) by smtp.gmail.com with ESMTPSA id 69sm12721100wrk.2.2017.08.22.03.57.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Aug 2017 03:57:28 -0700 (PDT) Subject: Re: ping [PATCH] [MSP430] Fix PR78849: ICE on initialization of global struct containing __int20 array To: Joseph Myers , Jeff Law Cc: gcc-patches@gcc.gnu.org References: <472ffbde-b1ec-bfca-4de1-505141e8397a@somniumtech.com> From: Jozef Lawrynowicz Message-ID: <3e1f1590-8fa0-a00a-cf1e-2a17de688ccb@somniumtech.com> Date: Tue, 22 Aug 2017 11:34:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-08/txt/msg01264.txt.bz2 On 02/08/2017 17:45, Joseph Myers wrote: > On Wed, 2 Aug 2017, Jeff Law wrote: > >> I think Joseph's suggestion for looking at partial float handling may be >> useful, though ia64's RFmode may be more interesting as it's not a >> multiple of 8 in bitsize. IF/KF modes on the ppc port have similar >> properties. > > The key issue those floating-point modes engage is the meaning of > precision. IFmode and KFmode have precision set to 106 and 113 to > distinguish them. But that's precision in the sense of number of mantissa > bits; as normally understood in GCC, precision should be the number of > significant bits, so 128 for both those modes (but having multiple > different binary floating-point modes with the same precision would > require changing how we deal with laying out long double, so the target > specifies a mode for floating-point types rather than leaving it to be > deduced from values such as LONG_DOUBLE_TYPE_SIZE). > Thanks for the advice, I'm looking into how the ppc KFmode behaves in this situation now. I also looked through the front end code a bit more, and the behaviour of stor-layout.c:layout_type for RECORD_TYPE looks likes a smoking gun to me. For BOOLEAN_TYPE, INTEGER_TYPE, ENUMERAL_TYPE, REAL_TYPE, FIXED_POINT_TYPE etc. layout_type sets: TYPE_SIZE (type) = bitsize_int (GET_MODE_BITSIZE (TYPE_MODE (type))); But for the individual field types in RECORD_TYPE, UNION_TYPE or QUAL_UNION_TYPE, this same setting of TYPE_SIZE and friends is not performed. So a field in a RECORD_TYPE might be an INTEGER_TYPE, but TYPE_SIZE for this INTEGER_TYPE will not be set as it would have been had the type not been a field in a RECORD_TYPE. So the fix to me looks to be to ensure that the code for the base types (BOOLEAN_TYPE, INTEGER_TYPE etc.) from layout_type is also executed for each type that happens to be a field in a RECORD/UNION/QUAL_UNION_TYPE.