Re: ping [PATCH] [MSP430] Fix PR78849: ICE on initialization of global struct containing __int20 array

[Jozef Lawrynowicz <jozef dot l at somniumtech dot com>]

On 22/08/2017 11:57, Jozef Lawrynowicz wrote:
> 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.

Actually, the issue turned out to be that TYPE_SIZE is specifically set
in the first place.
When the internal data structures to handle __intN types are initialised
in tree.c, the compiler is also setting TYPE_SIZE.

For the other "standard" types, layout_type sets TYPE_SIZE. So rather
than specifically setting TYPE_SIZE in tree.c, I've removed this code so
TYPE_SIZE will get set like it does for every other type.

If the attached patch is acceptable, I would appreciate if someone could
commit it for me, as I do not have write access.

Thanks,
Jozef

Attachment: 0001-MSP430-Dont-specifically-set-TYPE_SIZE-for-__intN-ty.patch
Description: Text document