This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ping [PATCH] [MSP430] Fix PR78849: ICE on initialization of global struct containing __int20 array
- From: Jeff Law <law at redhat dot com>
- To: Jozef Lawrynowicz <jozef dot l at somniumtech dot com>, Joseph Myers <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 2 Aug 2017 10:33:15 -0600
- Subject: Re: ping [PATCH] [MSP430] Fix PR78849: ICE on initialization of global struct containing __int20 array
- Authentication-results: sourceware.org; auth=none
- 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 at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com F2BC1356D8
- References: <CAG7DreZcfmbvFj_S-dZvC9wCxf3pSiw4q-Kum-4zDddAssvKgA@mail.gmail.com> <b8c38929-f683-21f6-ab01-9a0e4b915395@redhat.com> <alpine.DEB.2.20.1707312303140.19386@digraph.polyomino.org.uk> <472ffbde-b1ec-bfca-4de1-505141e8397a@somniumtech.com>
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