On 10 January 2008 16:40, Gabriele SVELTO wrote:
> Dave Korn wrote:
>> On 10 January 2008 16:12, Gabriele SVELTO wrote:
>>
> > [snip]
> >
>>> A new type still named 'struct try' is used in the COMPONENT_REFs of
>>> this function but this type has a different TYPE_UID from the 'struct try'
>>> used in main. Since the original type was local to main this makes sense.
>>
>> But the array is local to main as well ...
>
> But it's static so it needs to be initialized once before the function gets
> called AFAIK. gcc seems to be creating an artificial function for this task
> or at least that's how it looks. I've been working on gcc for only ~3
> months so I might be badly wrong on this one.
Yes, you're completely correct about the artificial initialiser function; I
thought the compiler might output it as a nested function, but I don't know
without checking. (But I've been working on gcc for only ~7 years so I might
be badly wrong on this or indeed any other one..... ;-P it's a big old pile of
code!)
>> Is this possibly because the new type is not "struct try" but "struct try
>> const"; it adds the const qualifier and refers back to the original "struct
>> try" for the fields?
>
> Yes, TYPE_READONLY () returns 1 on the new type so I guess it's const.
Really you should use CP_TYPE_CONST_P to test this; IIUC, things can be
const without being readonly (and perhaps even vice-versa), depending on which
kind of section (.data/.rdata) they're allocated to.
> So
> is it normal that the two types share the fields so that you can end up with
> DECL_FIELD_CONTEXT (TYPE_FIELDS (type)) != type ? Does this always happen
> when gcc creates a 'derived' const type from another one? Thanks for the
> help,
I believe this is indeed gcc's bog-standard way of creating a qualified
variant of an existing type. Note that you should see in this case that
TYPE_MAIN_VARIANT (type) == DECL_FIELD_CONTEXT (TYPE_FIELDS (type)), I think.
cheers,
DaveK
--
Can't think of a witty .sigline today....
