From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5557 invoked by alias); 17 Feb 2014 17:33:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5548 invoked by uid 89); 17 Feb 2014 17:33:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oa0-f51.google.com Received: from mail-oa0-f51.google.com (HELO mail-oa0-f51.google.com) (209.85.219.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 17 Feb 2014 17:33:09 +0000 Received: by mail-oa0-f51.google.com with SMTP id h16so18121927oag.10 for ; Mon, 17 Feb 2014 09:33:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UKGaJZbBfSm8HJcSCPoqgUSikPEHkqL5PVelg3pB+Ac=; b=HZnn8vmujxUP7uFz5Nd0qUUn/CW8+JG7KAhEC7M3y9d9i76Uy1tI1sXJroFT/5USI4 FhgcpIlevO53/FIFDW47U1v9P/quGe9SZogDeaeYDfrVisgqCbn1haS4cf7/2ZcsnE1D 0HamoXa4WzLoWHnd452RGF3L4i2YVotiedV1oGPaZkgJsYOW4/zH9VkT/5AfAkCr+i5n HJpEDXfb0w8nZlzFJ0F13Y6Eveh3I7OAj0IIK4ClPGQtZyWvLqJhSOetEFkRosb2wuDg nyNNcipfu5qQDZ68BzjCSvr/kXAd5Ag8cOVZ564y4JstCdSJjxU0fcnZGYZ2fVXVSkV+ 3How== X-Gm-Message-State: ALoCoQmbz9vjI26LAgYS6odhh3ugWC1TYpzVsaK+xbYENbwuuSTqzO4LBKbvejjyjDbnPWsbg0mmQxYM48cdo6VA+EQxC8t0HASE0zqlbnqRWAEI3QlFOWsd276BVKx0+kPjbR3393BSra9NA4Oy1EtT/4uJq2n7Weo18dHLYdbZA96HGa1DBSpdRQreLqrKQOjg25ifdmME MIME-Version: 1.0 X-Received: by 10.60.246.139 with SMTP id xw11mr22119945oec.36.1392658387525; Mon, 17 Feb 2014 09:33:07 -0800 (PST) Received: by 10.60.39.2 with HTTP; Mon, 17 Feb 2014 09:33:07 -0800 (PST) In-Reply-To: References: <20140214085908.GA5228@linux.vnet.ibm.com> <20140217121542.GA17780@linux.vnet.ibm.com> Date: Mon, 17 Feb 2014 17:33:00 -0000 Message-ID: Subject: Re: Need help: Is a VAR_DECL type builtin or not? From: Ian Lance Taylor To: Richard Biener Cc: vogt@linux.vnet.ibm.com, GCC Development Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00258.txt.bz2 On Mon, Feb 17, 2014 at 5:28 AM, Richard Biener wrote: > On Mon, Feb 17, 2014 at 1:15 PM, Dominik Vogt 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 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