This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [pointer size] more edge cases
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 16 Oct 2014 01:08:12 +0000
- Subject: Re: [pointer size] more edge cases
- Authentication-results: sourceware.org; auth=none
- References: <201410152229 dot s9FMTJrd012513 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1410152345310 dot 11645 at digraph dot polyomino dot org dot uk> <201410160018 dot s9G0I8kh000440 at greed dot delorie dot com>
On Wed, 15 Oct 2014, DJ Delorie wrote:
> > I don't see what the stor-layout.c changes have to do with that
> > description, or why they are correct (they look wrong to me; the
> > existing addition of BITS_PER_UNIT_LOG + 1 looks logically correct
> > for bitsizetype).
>
> sooo... the type for bitsizetype will *always* be a bigger type than
> sizetype? Even when sizetype is already the largest type the target
> can handle naturally?
It's expected to be larger, so that it can handle +/- the whole address
space, in bits. But that's subject to the bounds of MAX_FIXED_MODE_SIZE
and HOST_BITS_PER_DOUBLE_INT that are already present in the code.
(If any nontrivial, nonconstant calculation is being done in bitsizetype,
that should be unusual; if anything, I'd rather not have bitsizetype at
all, and use bytes and bits separately for calculations where bit offsets
are relevant. But under the existing logic, bitsizetype is expected to be
bigger than sizetype, even if inefficient.)
--
Joseph S. Myers
joseph@codesourcery.com