This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] change specific int128 -> generic intN
- From: DJ Delorie <dj at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 24 Jun 2014 01:51:46 -0400
- Subject: Re: [patch] change specific int128 -> generic intN
- Authentication-results: sourceware.org; auth=none
- References: <201404142303 dot s3EN3ONP009938 at greed dot delorie dot com> <201406211624 dot s5LGOFC8031566 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1406212014500 dot 29257 at digraph dot polyomino dot org dot uk>
> The changes to dwarf2asm.c, cppbuiltin.c, optabs.c, defaults.h, expr.c,
> expmed.c, tree-dfa.c, simplify-rtx.c, lto-object.c, loop-iv.c, varasm.c,
> the msp430 back end and some of the stor-layout.c changes don't look like
> they should depend on the rest of the patch. I think it would help review
> if anything that can reasonably be separated from the main intN support is
> posted separately, as a much smaller patch with its own self-contained
> rationale (I presume all those changes should work fine without the main
> intN support), and then the intN patch only contains things directly
> related to intN support.
There are basically three types of changes working together here:
1. Changes that remove the "types are powers of two" assumptions
throughout gcc. At least, as many as I could find. These could be
applied without the intN support, but serve no purpose without it.
2. The intN patch itself.
3. The msp430's changes to use __int20 for size_t, which depends on
the above two.
I'll split them up but I hope progress on set #2 isn't stalled on
bikeshedding set #1, especially since set #1 doesn't solve any
problems (or really, change *anything*) on its own.