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