From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47944 invoked by alias); 2 Aug 2017 16:33:21 -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 47924 invoked by uid 89); 2 Aug 2017 16:33:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=vary X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Aug 2017 16:33:18 +0000 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 mx1.redhat.com (Postfix) with ESMTPS id F2BC1356D8; Wed, 2 Aug 2017 16:33:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F2BC1356D8 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law@redhat.com Received: from localhost.localdomain (ovpn-116-95.phx2.redhat.com [10.3.116.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4EB587FB77; Wed, 2 Aug 2017 16:33:16 +0000 (UTC) Subject: Re: ping [PATCH] [MSP430] Fix PR78849: ICE on initialization of global struct containing __int20 array To: Jozef Lawrynowicz , Joseph Myers Cc: gcc-patches@gcc.gnu.org References: <472ffbde-b1ec-bfca-4de1-505141e8397a@somniumtech.com> From: Jeff Law Message-ID: Date: Wed, 02 Aug 2017 16:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <472ffbde-b1ec-bfca-4de1-505141e8397a@somniumtech.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00201.txt.bz2 On 08/01/2017 10:26 AM, Jozef Lawrynowicz wrote: > On 01/08/2017 00:08, Joseph Myers wrote: >> On Wed, 26 Jul 2017, Jeff Law wrote: >> >>> TYPE_SIZE, according to my understanding, should be a tree for the size >>> of the expression in bits. >>> >>> The problem is for msp430 that size varies depending on where it's used. >>> ie, in a register an object might have a bitsize of 20 bits, but in >>> memory its size is 32 bits. >>> >>> I don't think that TYPE_SIZE has any concept that the use context is >>> relevant to selecting the proper size. >> >> TYPE_SIZE_UNIT is unambiguously the memory size, including padding; it's >> used for sizeof. TYPE_SIZE may be less clear. We've had issues before >> with unions with x87 long double, which has 80-bit precision in registers >> but is 12-byte or 16-byte in memory; that was wrong code (bug 71522) >> rather than an ICE, but the long double case may be useful for comparison >> of what various type properties are set to in such cases. >> > > Thanks for the responses. > > Could it be possible to use "variable_size" to help the compiler choose > which size to use for TYPE_SIZE? Although the problem I see with this > right away is that variable_size is never executed on an INTEGER_CST, > perhaps this is part of the problem? I suspect variable_size is more for things like VLAs where the size of an array may vary at runtime. What we're dealing here is more that the size of an object varies depending on if it's in a register or in memory. > Zooming out a bit from TYPE_SIZE, the value that ends up being incorrect > as a result of TYPE_SIZE is rli->bitpos, this value is used a lot in > stor_layout.c:place_field, perhaps I need to look deeper in there. 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. If you could declare a type that corresponds to one of those modes, then build an array of them and follow how that code works it might give you some hints on how to fix intXX. jeff