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
jos...@codesourcery.com
