This is the mail archive of the gcc@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: Question on gimplify.c:create_tmp_var


    This seems to me to be a huge representational mistake.

    It seems to me that this is best represented using a temporary structure
    internal to the compiler, r1_prime, which is has the maximum size of r1
    and contains a single field of type r1.  Then when you write "x.f5" at the
    source level, the compiler actually generates "x.f5.real_r1".

    No muss, no fuss, no disgusting things happening with lvalue casts.
    Further, it seems to me that it preserves the original language type
    system better than whatever you've been doing before.

Let me try again.

This was actually a bad example because indeed this is three nested
COMPONENT_REFERENCEs due to the fact that a "padded" type is actually made.

But there's a basic issue here, which is independent of the details.

The issue is that the "real" type of f5 isn't known at the language level.
We want, as much as possible, to have a 1-1 mapping between Ada and GCC
tree nodes.

So we have two operations x.f5 and (x.f5).f1.  In both the GCC and Ada
trees, this is a component reference, with two operands: one a "name"
and one a field declaration.  x.f5 has a type of r1 in the Ada tree.  So
the GCC tree corresponding to that operation should have the type
corresponding to that Ada type of r1.  Likewise (x.f5).f1 has an *input*
type of r1 and the "f1" corresponds to the FIELD_DECL in r1.

The logical thing to do is to first do x.f5.  If that ended up being some
subtype, we convert it to r1.  The the second operation has an input type
of r1, so all is fine.  

If we leave the result of x.f5 in its GCC type even if it isn't the Ada
type, we have a problem with the outer operation.  For one thing, the
reference to "f1" corresponds to a FIELD_DECL in r1, as I said.  So we'd have
to search for the corresponding FIELD_DECL in the "real" GCC type.  Since
we can be talking about types with hundreds of fields, that can be an
expensive operation.

As another case, consider:

	type r1 is record f1: integer; f2: character; end record;

r1 is aligned to a 4-byte boundary, so its normal size is 64 bits.
But it actually only needs 40 bits.  It's valid in Ada to then write

	type r2 is record
	   f3: r1;
	   f4, f5, f6: character;
	end record;
	for r2 use record
	   f3 at 0 range 0..39;
	   f4 at 5 range 0..7;
	   f5 at 6 range 0..7;
	   f6 at 7 range 0..7;
        end record;

So we're forcing F3 to be a smaller record.  We do this by making another
type corresponding to r1 that's packed down and we make f3 a bitfield.

But now if we have an object of type r2, say, x, and we do x.f3.f1, again
we have a situation where the GCC type of (x.f3) is does not correspond
to the Ada type of that operation.  So all the above applies.


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