public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dominik Vogt <vogt@linux.vnet.ibm.com>
To: GCC Development <gcc@gcc.gnu.org>
Cc: Richard Biener <richard.guenther@gmail.com>
Subject: Re: Need help: Is a VAR_DECL type builtin or not?
Date: Mon, 17 Feb 2014 12:15:00 -0000	[thread overview]
Message-ID: <20140217121542.GA17780@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAFiYyc1HbvtrmGjoBA1DXtFNtkdbJAVbC6inpG_TNz_pTjfhGg@mail.gmail.com>

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

  reply	other threads:[~2014-02-17 12:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-14  8:59 Dominik Vogt
2014-02-14 13:40 ` Richard Biener
2014-02-17 12:15   ` Dominik Vogt [this message]
2014-02-17 13:28     ` Richard Biener
2014-02-17 17:33       ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140217121542.GA17780@linux.vnet.ibm.com \
    --to=vogt@linux.vnet.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).