This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: locating unsigned type for non-standard precision


On Tue, Apr 24, 2012 at 9:01 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 24, 2012 at 3:50 PM, Peter Bigot <bigotp@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]