http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53103
Bug #: 53103
Summary: bug locating unsigned type for non-standard precision
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org
gcc segfaults with this code:
typedef long int __attribute__((__a20__)) int20_t;
int20_t xi;
int20_t addit () { xi += 0x54321L; }
in a back end where 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. 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 integer (instead
of the 20-bit one it might have used), and infinite recursion through
convert results.
Per http://gcc.gnu.org/ml/gcc/2012-04/msg00805.html, recommendation is to
abort the optimization if the required type is not selected.
