Re: PR middle-end/30017 (ICE in C++ size hook)

[Jan Hubicka <jh at suse dot cz>]

> Jan Hubicka wrote:
> 
> > Yes, I think what we have problem with is mixing the two highlevel and
> > lowlevel point of views.  For C++ up to gimplification it is perfectly
> > valid to stick on the C++ conventions (such as requiring copy
> > constructor to be used at copies), after gimplification we however
> > should make IL independent on such a details so the structure remains
> > just structure.
> 
> I'm not sure I agree.  In general, the backend *must not* copy these
> objects, as that would violate the C++ semantics.  We could have a flag

I am not quite sure I folow your logic here either.  Perhaps some
example would help.

It seems to me that at low level all those objects are just hunks of
data identical to C structures/unions.  We don't silently introduce
copies of those either as the semantic would change too, for instance
when their address is taken.  We might want to copy propagate or do
similar optimizations (we don't do at moment AFAIK) later if we can
prove that this does not matter (ie either address is never taken from
the object or used in simple way we can understand and we know the
object is not overwritten etc.)

It seems to me that C++ is actually more relaxed here giving the
mechanizm to copy data around via copy constructors (compiler is not
allowed to use them completely freely either, right?), but we might
safely forget about that information without breaking the semantics.

> on the objects (or their types) to indicate that that, but these hunks
> of data are different from most of hunks of data in that the backend
> does not have the freedom to copy them about.
> 
> There are some special cases (like this memcpy case) where the copy is
> OK -- but even in those cases asking for the size of these expressions
> doesn't make sense.  Fundamentally, the size is not knowable.
> 
> > This is supposed to check that the size of block to be copied by
> > assignment is the same as size of memcpy operand.  However the later
> > expanding code use the expr_size hook to compute this value and it
> > crash.
> 
> Can we pass down the known size, so that calling the expr_size hook is
> unnecessary?  As per the above, there's no right answer, in general, for
> "what's the size of this C++ object of type X", so using the expr_size
> hook is sketchy.

We perhaps might play around with with_size_expr, but I don't think it
is good idea here.  Whole point of introducing the assignment is to
allow optimizations later in queue to happen (such as copy propagation)
and making them compatible with WITH_SIZE_EXPR is somewhat tricky too.

I guess if the type size is really undefined and we don't want to introduce
any notion of it, we just need to find way to disable the transformation
on those cases, probably by using the expr_size hook to return NULL as I
outlined in previous mail.

The problem is that the code quote uses TYPE_UNIT_SIZE believing that
the value contains the type size.  (ie the transformation happen only
when the memcpy operand is identical to TYPE_UNIT_SIZE if defined.)
Perhaps it should be set NULL then by C++ frontend as documenation
suggest?:

@item TYPE_SIZE
The number of bits required to represent the type, represented as an
@code{INTEGER_CST}.  For an incomplete type, @code{TYPE_SIZE} will be
@code{NULL_TREE}.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713