This is the mail archive of the
mailing list for the GCC project.
Re: __intN patch 3/5: main __int128 -> __intN conversion.
- From: Jason Merrill <jason at redhat dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: nathan at codesourcery dot com, gcc-patches at gcc dot gnu dot org
- Date: Thu, 02 Oct 2014 10:22:28 -0400
- Subject: Re: __intN patch 3/5: main __int128 -> __intN conversion.
- Authentication-results: sourceware.org; auth=none
- References: <201408132211 dot s7DMBGBu016387 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1408212030310 dot 16900 at digraph dot polyomino dot org dot uk> <201408212123 dot s7LLNPIQ018746 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1408212131060 dot 16900 at digraph dot polyomino dot org dot uk> <201408220515 dot s7M5Fhpa007479 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1408221051550 dot 5292 at digraph dot polyomino dot org dot uk> <201408221924 dot s7MJOcjB022631 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1408222013390 dot 16713 at digraph dot polyomino dot org dot uk> <201408260303 dot s7Q33nqm024601 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1409012142450 dot 7370 at digraph dot polyomino dot org dot uk> <201409302314 dot s8UNE7LP020494 at greed dot delorie dot com> <542CC4FA dot 70609 at redhat dot com> <201410020352 dot s923qLlm002274 at greed dot delorie dot com>
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
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
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
We still need mangling tests for __int20, though.