On Tue, Apr 24, 2012 at 9:01 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> On Tue, Apr 24, 2012 at 3:50 PM, Peter Bigot <big...@acm.org> wrote:
>> I've run into another issue supporting a 20-bit integer for which I'd
>> appreciate a hint. With this code:
>>
>> typedef long int __attribute__((__a20__)) int20_t;
>> int20_t xi;
>> int20_t addit () { xi += 0x54321L; }
>>
>> xi ends up in mode PSImode, which is a MODE_PARTIAL_INT with 20 bits of
>> precision and 32-bit width.
>>
>> convert() notices that, because the constant in the add expression is
>> SImode, there's an SImode add being truncated to a PSImode result, and
>> pushes the truncation down into the operands.
>>
>> The problem is this ends up in convert_to_integer, which detects that the
>> signed operation might overflow so calls unsigned_type_for() to get the
>> unsigned variant.
>>
>> Unfortunately, this ends up in c_common_type_for_size(), which knows nothing
>> about PSImode, and returns an unsigned type with 32 bits of precision when
>> asked for one with 20 bits of precision.
>
> That's expected - this function returns a type that is suitable for holding
> all
> values, not a type that has necessarily matching precision. If the caller
> wants such type it needs to verify what the function returned. Which seems
> to me to be the correct fix for this (premature) optimization in
> convert_to_integer.
Thanks; I'll fix it that way and file a bug report to track it.
Peter
