You keep saying "If we had done this by creating new types, it would be
a mess", but what we have *now* is a mess.
I seriously doubt the "mess" created by having new types for objects of
new sizes would be greater than what we have now.
I disagree. The mess we have right now is
On Fri, 2005-10-07 at 08:26 -0400, Richard Kenner wrote:
> Personally, I would have not had a DECL_SIZE, i would have made
> TYPE_SIZE express the type size properly (IE not always a multiple).
>
> What is the incredibly good reason we have them both, other than to save
> memory in
Daniel Berlin wrote:
> Thinking harder about it, you might be better off then making
> everything based on TYPE_SIZE then, since we don't always have the
> FIELD_DECL's handy.
[...]
> i meant in tree-ssa-structalias.c. The results you get by doing this
> should be fine.
Oh, OK. Will look into
Personally, I would have not had a DECL_SIZE, i would have made
TYPE_SIZE express the type size properly (IE not always a multiple).
What is the incredibly good reason we have them both, other than to save
memory in the number of bitfield types we create?
Because we need to have a
> > precision 3 min max >
>
> You'll note we actually created a new type for this :)
Indeed, and I think we also have that in Ada, my confusion.
Actually, I don't think we do and I recall a discussion a few weeks
ago that it would be incorrect Ada semantics to do it. But
On Fri, 2005-10-07 at 07:35 -0400, Richard Kenner wrote:
> This is the correct fix, however, if you are going to lie to the
> middle end about TYPE_SIZE so that the TYPE_SIZE and DECL_SIZE do not
> match.
>
> If we always require that DECL_SIZE be identical to TYPE_SIZE, why
> have
This is the correct fix, however, if you are going to lie to the
middle end about TYPE_SIZE so that the TYPE_SIZE and DECL_SIZE do not
match.
If we always require that DECL_SIZE be identical to TYPE_SIZE, why
have a DECL_SIZE in the first place? But how else would you support
bitf
> > Thinking harder about it, you might be better off then making
> > everything based on TYPE_SIZE then, since we don't always have the
> > FIELD_DECL's handy.
>
> I'm not sure we can.
>
> I think we must have an integral mode (and size) for the type to be
> able to place the field on a
Richard Henderson wrote:
> > precision 3 min max >
> ^^^
>
> Actually, we did create a different type just for this bitsize.
Indeed, my comment was confused on that account.
> Not that that detracts from the fact that TYPE_SIZE is always a
> multiple of BITS_PER_UNIT.
Agr
Daniel Berlin wrote:
> >
> > size
> > > size
> > precision 3 min max >
>
> You'll note we actually created a new type for this :)
Indeed, and I think we also have that in Ada, my confusion. The
TYPE_SIZE is still larger than the DECL_SIZE above, and the field
rea
On Oct 6, 2005, at 4:22 PM, Olivier Hainque wrote:
Daniel Berlin wrote:
IOW, you are lying to the middle-end about the size of the fields.
Why is the type not a 6 bit integer?
layout_decl (tree decl, unsigned int known_align)
...
/* Usually the size and mode come from the data type
On Thu, Oct 06, 2005 at 10:22:08PM +0200, Olivier Hainque wrote:
> Because we avoid creating a different type for every possible
> bitsize...
...
> The C front-end behaves similarily, creating
...
> precision 3 min max >
^^^
Actually, we did create a different type just f
Daniel Berlin wrote:
> IOW, you are lying to the middle-end about the size of the fields.
> Why is the type not a 6 bit integer?
Because we avoid creating a different type for every possible
bitsize, which seems to be the purpose of DECL_SIZE in the
first place and is explicitly expected by the
On Oct 6, 2005, at 12:00 PM, Olivier Hainque wrote:
Hello,
The Ada testcase below, compiled with -O2 on x86-linux, triggers a
SEGV in the current mainline compiler, there:
do_simple_structure_copy
{ ...
for (; p && p->offset < last; p = p->next)
{ ...
q = first_vi_f
14 matches
Mail list logo
