This is the mail archive of the 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: C++ PATCH to refer to base members using COMPONENT_REF

Jason Merrill wrote:

On Mon, 03 May 2004 13:23:48 -0700, Mark Mitchell <> wrote:

Jason Merrill wrote:

	(layout_class_type): Change base fields to their real type
	after layout is done.

This particular part of your change seems dangerous to me.

I wondered about it myself, but concluded that it's safe.

It might tell the alias analysis code that assignment to the base field
might alias any of the types of the fields in the complete type when really
it can only alias things in the base type.

I don't think so.  The base type does not alias other members of the
derived type.

I don't understand. The base field, after your change, will have the type of the derived class. So, an assignment to that entire field (e.g., x.__base = y.__base) would tell the type-based alias analysis that any object have the type of any field *in the derived type* could be read/written. Or, did you do something to prevent that from happening?

Also, it makes it hard for us to use the base fields in other places
(like assignments generated by copy constructors) where it might be
advantageous to the optimizers to see what was really going on.  (We
can't use them any more because they'll have types that don't match
reality.  Also, DECL_FIELD_SIZE and TYPE_SIZE will probably not match any

But we only use the tail padding for non-PODs, which we have to deal with
on a member-by-member basis anyway.

That's only true until we start recognizing that some constructors are trivial. Then, the front end will start treating some non-PODs as if they were PODs for the purpose of copying.

I think you should instead leave the base field types as they are, but use
FIELD_DECLs from the base type instead of the complete type.

The offsets would be wrong for non-primary bases unless we did something
like make copies of the FIELD_DECLs for use in derived types.

I'm not sure why that would be. But, I believe you -- I'm probably just not thinking about it right.

Fundamentally, my objection to this patch is that it's causing us to lie to the compiler. From the point of view of the language, these fields don't exist, so that's not an issue. From the point of view of the compiler, however, these fields do not have the same type as the derived type, or the same size. The relationship is that the base fields are an initial prefix of the derived class. After your change, we've busted the type system -- there are type-safe assignments that are not actually safe, for example. Historically, whenever we've lied like this, we've gotten into trouble.

Mark Mitchell
CodeSourcery, LLC

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