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
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.