This is the mail archive of the 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]

locating unsigned type for non-standard precision

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.? The expression is rewritten with
the 32-bit constant integer recast to the 32-bit unsigned type (instead
of the 20-bit one it might have used), and infinite recursion results.

Is it proper for c_common_type_for_size() to know about partial int modes
and return the best one available?? Is there a hook that would allow me to
do this customized in my back-end?? Or is there another way to get
unsigned_type_for() to return the "right" type for an unusual integer



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