Re: [PATCH, pretty-ipa] Fix wave ICE in SRA

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, May 7, 2009 at 12:50 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Thu, 7 May 2009, Richard Guenther wrote:
>
>> > ?if (TREE_CODE (exp) == COMPONENT_REF)
>> > ? ?size_tree = TYPE_SIZE (TREE_TYPE (TREE_OPERAND (exp, 1)));
>> > ?else if ...and so on...
>> >
>> > is wrong, it's DECL_SIZE (TREE_OPERAND (exp, 1)).
>>
>> They should be exchangable in the context of an access.
>
> As pointed out, you always should use DECL_SIZE if available. ?IMO.
>
> ...
>
> May I say that this whole thing looks rather disturbing, mismatching
> random mixes of different TYPE_ or DECL_SIZEs on the same assignment can't
> be a good sign of a proper intermediate representation. ?Except for very
> good reasons, maybe bitfields, but a simple copy from a base variable ...
>
> IMO that variable shouldn't have had a DECL_SIZE that includes alignment ...
> I would understand that TYPE_SIZE includes it (and only for the reason
> that constructing arrays of such elements then implicitely includes the
> alignment when going from one to the next member).
>
>
>> ?At least
>> ? ... = x.a;
>> and
>>
>> ? p = &x.a;
>> ? ... = *p;
>>
>> already have different sizes and that better should not matter(?).
>
> Well, if typeof(*p) has larger alignment (and hence TYPE_SIZE) than
> typeof(x.a) you have a problem when the end of x.a lies exactly on a page
> border for instance, and you want to copy too many bytes. ?Weren't there
> even bugreports about exactly such situation?

I think they would be valid only if the type is packed in which case
TYPE_SIZE would always match the decl or field size.

> (Of course *p shouldn't have larger alignment from the start to not
> introduce unaligned accesses, but in that case they also will have the
> same TYPE_SIZEs again, so I stay by my nervousness about mismatching
> TYPE/DECL_SIZEs)

Hm, at least I cannot reproduce with a simple C testcase:

struct A {
  int i;
  char c;
};
struct B {
  struct A a;
  int b;
};
void foo(void)
{
  struct A a;
  struct B b;
  struct A *p = &b.a;
  *p = a;
}

the FIELD_DECL b.a has size 8, just like the struct A type has.
I suppose with C++ the situation may be different because of
tail packing.  For example with

struct A {
  A() {}
  int i;
  char c;
};
struct B : A {
  B() {}
  char c;
};
void foo(void)
{
  A a;
  B b;
  A *p = &b;
  *p = a;
  static_cast<A&>(b) = a;
}

the anonymous field-decl for the base A has a DECL_SIZE not
including the tail padding.  But the C++ FE is very careful to
use memcpy for both assignments _not_ including the tail
padding.

So I'm curious where we end up generating this possibly
bogus assignment statement ...

Richard.