This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]