On 10/01/2014 11:52 PM, DJ Delorie wrote:
It seems like the int128 code here was broken and this is continuing
that brokenness. Extended integer types have integer conversion rank
corresponding to their bitsize, so int128 should have higher rank than
long long, but here it was being checked after long long, and your code
also follows the long long code. Also, we should be checking for both
signed and unsigned variants.
In this case, we know that the two types are the same bitsize.
True, when __int128 is the same size as long long it has lower rank.
But it isn't always the same size; specifically, in the x32 ABI long
long is 64 bits. So we definitely need to deal with extended integer
types larger than long long.
If you plan to allow __intN with sizes between those of int and long
long, they need to have the appropriate intermediate conversion rank for
their size.
But... we don't know the bit sizes at the gcc source level, we only
know them by iterating the array. We'd have to iterate the array at
evey step to see if it's between bitsize N and M, or add the standard
types to some array, or add the __intN variants to integer_types[] and
re-sort i_t[].
Right.
However, doing that introduces the __intN types to
*everything* that uses integer_types[]. I was hesitant to add
nonstandard types to the standard promotion rules.
The C++ standard says that extended integer types participate in the
usual arithmetic conversions. If I add a 32-bit int and an __int48, the
usual arithmetic conversions should convert the int to __int48.
I don't mind if you deal with this by asserting that extended integer
types never fall between int and long long rather than actually trying
to support it.
Extended integer types larger than long long also participate in
enumeral promotion if needed, but I think your changes to
c_common_type_for_size handle that.
Basically I think the integral conversion code in cp_common_type ought
to be rewritten to work on integer_types rather than naming specific types.
That would be the "re-sort it" option.
- 'n', /* itk_int128 */
- 'o', /* itk_unsigned_int128 */
+ /* __intN types are handled separately */
Where are they mangled now? I also don't see any mangling tests.
They mangle as Inn like I20 or I128 (that might be the wrong letter,
but the syntax is like that). It surprised me that there was a case
for "other unknown types", but there's a case for it :-)
Ah, I see that 'n' and 'o' for __int128 are handled further down in
write_builtin_type. And we do have mangling tests for that
(g++.dg/abi/mangle43.C).
We still need mangling tests for __int20, though.
Jason
