Re: Need help: Is a VAR_DECL type builtin or not?

[Ian Lance Taylor <iant@google.com>]

On Mon, Feb 17, 2014 at 5:28 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, Feb 17, 2014 at 1:15 PM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
>> On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
>>> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
>>> > Given a specific VAR_DECL tree node, I need to find out whether
>>> > its type is built in or not.  Up to now I have
>>> >
>>> >   tree tn = TYPE_NAME (TREE_TYPE (var_decl));
>>> >   if (tn != NULL_TREE && TREE_CODE (tn) == TYPE_DECL && DECL_NAME (tn))
>>> >     {
>>> >       ...
>>> >     }
>>> >
>>> > This if-condition is true for both,
>>> >
>>> >   int x;
>>> >   const int x;
>>> >   ...
>>> >
>>> > and
>>> >
>>> >   typedef int i_t;
>>> >   i_t x;
>>> >   const i_t x;
>>> >   ...
>>> >
>>> > I need to weed out the class of VAR_DECLs that directly use built
>>> > in types.
>>>
>>> Try DECL_IS_BUILTIN.  But I question how you define "builtin" here?
>>
>> Well, actually I'm working on the variable output function in
>> godump.c.  At the moment, if the code comes across
>>
>>   typedef char c_t
>>   chat c1;
>>   c_t c2;
>>
>> it emits
>>
>>   type _c_t byte
>>   var c1 byte
>>   var c2 byte
>>
>> This is fine for c1, but for c2 it should really use the type:
>>
>>   var c2 _c_t
>>
>> So the rule I'm trying to implement is:
>>
>>   Given a Tree node that is a VAR_DECL, if its type is an "alias"
>>   (defined with typedef/union/struct/class etc.), use the name of
>>   the alias, otherwise resolve the type recursively until only
>>   types built into the language are left.
>>
>> It's really only about the underlying data types (int, float,
>> _Complex etc.), not about storage classes, pointers, attributes,
>> qualifiers etc.
>>
>> Well, since godump.c already caches all declarations it has come
>> across, I could assume that these declarations are not built-in
>> and use that in the "rule" above.
>
> Not sure what GO presents us as location info, but DECL_IS_BUILTIN
> looks if the line the type was declared is sth "impossible" (reserved
> and supposed to be used for all types that do not have to be declared).

godump.c is actually not used by the Go frontend.  The purpose of
godump.c is to read C header files and dump them in a Go
representation.  It's used when building the Go library, to get Go
versions of system structures like struct stat.

I'm not quite sure what Dominik is after.  For system structures using
the basic type, the underlying type of a typedef, is normally what you
want.  But to answer the question as stated, I think I would look at
functions like is_naming_typedef_decl in dwarf2out.c, since this
sounds like the kind of question that debug info needs to sort out.

Ian