This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] avoid chainon when building record types in Fortran FE
- From: Nathan Froyd <froydnj at codesourcery dot com>
- To: Mikael Morin <mikael dot morin at sfr dot fr>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Fri, 2 Jul 2010 12:58:31 -0700
- Subject: Re: [PATCH] avoid chainon when building record types in Fortran FE
- References: <20100702134406.GC17877@codesourcery.com> <4C2E041A.email@example.com>
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->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
Since you approved it without the changes, I've committed the patch as
161738. Thanks for the review.