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: [PATCH] avoid chainon when building record types in Fortran FE


On Fri, Jul 02, 2010 at 05:22:02PM +0200, Mikael Morin wrote:
> Le 02.07.2010 15:44, Nathan Froyd a écrit :
>> @@ -1853,26 +1841,44 @@ gfc_finish_type (tree type)
>>   }
>>   
>>   /* Add a field of given NAME and TYPE to the context of a UNION_TYPE
>> -   or RECORD_TYPE pointed to by STYPE.  The new field is chained
>> -   to the fieldlist pointed to by FIELDLIST.
>> +   or RECORD_TYPE pointed to by CONTEXT.  The new field is chained
>> +   to the fieldlist pointed to by FIELDLIST through *CHAIN.
>>
>>      Returns a pointer to the new field.  */
>>
>> +static tree
>> +gfc_add_field_to_struct_1 (tree *fieldlist, tree context,
>> +				 tree name, tree type, tree **chain)
>> +{
>> +  tree decl = build_decl (input_location, FIELD_DECL, name, type);
>> +
>> +  DECL_CONTEXT (decl) = context;
>> +  TREE_CHAIN (decl) = NULL_TREE;
>> +  if (*fieldlist == NULL_TREE)
>> +    *fieldlist = decl;
> It seems you can remove fieldlist from the the parameters and use  
> TYPE_FIELDS(context) instead here.
> OK with that change.
> Actually, OK even without it.

That's a good point.  It even seems obvious now that you mention it.
That would permit removing &fieldlist from all the other calls to this
function and just using TYPE_FIELDS (context).  But it doesn't work,
because at this call, in trans-types.c:gfc_get_derived_type:

      /* Create a backend_decl for the __c_ptr_c_address field.  */
      derived->components->backend_decl =
	gfc_add_field_to_struct (&(derived->backend_decl->type.values),
				 derived->backend_decl,
				 get_identifier (derived->components->name),
				 gfc_typenode_for_spec (
				 &(derived->components->ts)), NULL);

derived->backend_decl isn't a RECORD_TYPE-looking thing: it's a
POINTER_TYPE.  So it doesn't have TYPE_FIELDS, and an --enable-checking
build breaks.  This code looks quite dodgy anyway: why is the type field
being accessed directly?  And why are we adding a FIELD_DECL to a
POINTER_TYPE?

Since you approved it without the changes, I've committed the patch as
161738.  Thanks for the review.

-Nathan


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