public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Need help: Is a VAR_DECL type builtin or not?
@ 2014-02-14  8:59 Dominik Vogt
  2014-02-14 13:40 ` Richard Biener
  0 siblings, 1 reply; 5+ messages in thread
From: Dominik Vogt @ 2014-02-14  8:59 UTC (permalink / raw)
  To: gcc

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.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Need help: Is a VAR_DECL type builtin or not?
  2014-02-14  8:59 Need help: Is a VAR_DECL type builtin or not? Dominik Vogt
@ 2014-02-14 13:40 ` Richard Biener
  2014-02-17 12:15   ` Dominik Vogt
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Biener @ 2014-02-14 13:40 UTC (permalink / raw)
  To: vogt; +Cc: GCC Development

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?

Richard.

> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
> IBM Germany
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Need help: Is a VAR_DECL type builtin or not?
  2014-02-14 13:40 ` Richard Biener
@ 2014-02-17 12:15   ` Dominik Vogt
  2014-02-17 13:28     ` Richard Biener
  0 siblings, 1 reply; 5+ messages in thread
From: Dominik Vogt @ 2014-02-17 12:15 UTC (permalink / raw)
  To: GCC Development; +Cc: Richard Biener

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.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Need help: Is a VAR_DECL type builtin or not?
  2014-02-17 12:15   ` Dominik Vogt
@ 2014-02-17 13:28     ` Richard Biener
  2014-02-17 17:33       ` Ian Lance Taylor
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Biener @ 2014-02-17 13:28 UTC (permalink / raw)
  To: vogt; +Cc: GCC Development

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).

Richard.

> Ciao
>
> Dominik ^_^  ^_^
>
> --
>
> Dominik Vogt
> IBM Germany
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Need help: Is a VAR_DECL type builtin or not?
  2014-02-17 13:28     ` Richard Biener
@ 2014-02-17 17:33       ` Ian Lance Taylor
  0 siblings, 0 replies; 5+ messages in thread
From: Ian Lance Taylor @ 2014-02-17 17:33 UTC (permalink / raw)
  To: Richard Biener; +Cc: vogt, GCC Development

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-02-17 17:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-14  8:59 Need help: Is a VAR_DECL type builtin or not? Dominik Vogt
2014-02-14 13:40 ` Richard Biener
2014-02-17 12:15   ` Dominik Vogt
2014-02-17 13:28     ` Richard Biener
2014-02-17 17:33       ` Ian Lance Taylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).