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
next prev parent 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).