Traversing typedef hierarchy in C/C++ tree
Hi,
I am trying to figure out how to get a typedef hierarchy from the C/C++
tree in GCC. Consider the following declarations:
struct s {};
typedef s s_t;
typedef s_t my_s_t;
my_s_t x;
Giveb 'x' VAR_DECL I can have this traversal using TYPE_MAIN_VARIANT():
x -> my_s_t -> s;
What I am trying to achieve is this:
x -> my_s_t -> s_t -> s
I looked at TYPE_NEXT_VARIANT(), but this is a list while what I need
is a tree (hierarchy).
Some background on why I need this: I would like to determine if a
member of a class is size_t so that I can always map it to a 64-bit
integer in another system (RDBMS). In other words:
struct s
{
unsigned int i;// -> 32-bit int
size_t s; // -> 64-bit int
}
Even though size_t might be typedef'ed as unsigned int. In the above
example I can do it. However, adding a level or indirections causes
problems:
typedef size_t my_size;
struct s
{
my_size s; // TYPE_MAIN_VARIANT(my_size) == unsigned int
}
Any ideas will be much appreciated.
Boris
unreferenced main in embedded source code
Hi everybody, i'm programming for embedded system and for work i use a code warrior ide (for freescale microprocessor). Our client has required to clean every warning in souce code. The codewarrior compiler don't detect every warning and so the client said to use a gcc -Wall and lint command. In our source code,we don't use a classic main(), but we specified at the IDE how is the main() and it compile fine, but when i run gcc -Wall, i reached the error for "undefined reference to `main' ". Is it possible specify my entry point as main()? Best regarding, Domenico
Re: [pph] Merge from trunk rev
On Tue, 19 Apr 2011, Diego Novillo wrote:
> This merge brings the branch up to rev 172662.
>
> There are some LTO failures which are ICEs induced by a new
> assertion I added in bp_pack_value. We discussed this in
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01115.html.
>
> The failure happens when we try to pack DECL_OFFSET_ALIGN. We
> only try to pack 8 bits, but in the case of
> testsuite/gcc.c-torture/execute/20010904-1.c, DECL_OFFSET_ALIGN
> is a very large 64 bit quantity:
>
> typedef struct x { int a; int b; } __attribute__((aligned(32))) X;
>
> #define DECL_OFFSET_ALIGN(NODE) \
> (((unsigned HOST_WIDE_INT)1) << FIELD_DECL_CHECK
> (NODE)->decl_common.off_align)
>
> Whether correctly or incorrectly, for field 'a',
> decl_common.off_align is 0xff. So, DECL_OFFSET_ALIGN is 1 << 0xff
> this triggers the assert I added.
I suppose it's a middle-end issue that for offset zero we note
an "infinite" amount of always zero low-order bits. We're lucky
(again) that DECL_OFFSET_ALIGN is streamed last. I think we should
fix this by not streaming using the macros that derive sth from
the actual values but by streaming the values themselves
(decl_common.off_align in this case).
> Now, this happens during WPA, so I'm suspecting some bad values
> being streamed.
I think they are not bad values, we just store something bogus.
> Richi, I think it's better if we ICE than if we silently cut
> these values short.
Sure, even better if we stream something useful ;)
Richard.
Re: Traversing typedef hierarchy in C/C++ tree
On 20 April 2011 08:37, Boris Kolpackov wrote:
> Hi,
>
> I am trying to figure out how to get a typedef hierarchy from the C/C++
> tree in GCC. Consider the following declarations:
>
> struct s {};
>
> typedef s s_t;
> typedef s_t my_s_t;
I don't know if GCC keeps the information you want, but according to
the language rules there is no hierarchy. There's a type, and zero or
more alternative names for it. The example above makes my_s_t a
synonym for s, not s_t.
Consider this valid code:
typedef int foo;
typedef int bar;
typedef foo bar;
typedef bar foo;
What do you expect to see here?
You want to track size_t, what if someone uses __typeof__(sizeof(1)),
does that count? What about std::size_t? That could be defined as a
synonym for __SIZE_TYPE__ or decltype(sizeof(1)) so is not in a
sequence of typedef declarations that includes size_t.
Re: Traversing typedef hierarchy in C/C++ tree
Hi Jonathan, Jonathan Wakely writes: > I don't know if GCC keeps the information you want, but according to > the language rules there is no hierarchy. There's a type, and zero or > more alternative names for it. The example above makes my_s_t a > synonym for s, not s_t. Right. "Hierarchy" was probably a poor choice of a term for this. I didn't mean hierarchy in the language sense but in the AST sense. GCC already creates a separate *_TYPE node for each typedef alias. And you can get from any such node to the "primary node", or root of the tree, using the TYPE_MAIN_VARIANT() macro. What I want is to get the parent node, not the root node. > Consider this valid code: > > typedef int foo; > typedef int bar; > typedef foo bar; > typedef bar foo; > > What do you expect to see here? Any sensible (e.g., ignoring all re-declarations) tree would work for me. I don't particularly care if my code doesn't produce the desired result for clinical cases like the above. > You want to track size_t, what if someone uses __typeof__(sizeof(1)), > does that count? I am fine with it not counting. > What about std::size_t? This one is actually covered. In GCC AST std::size_t node is the same as ::size_t (i.e., GCC does not create new *_TYPE node for using- declarations). > That could be defined as a synonym for __SIZE_TYPE__ or decltype(sizeof(1)) > so is not in a sequence of typedef declarations that includes size_t. If it were defined as one of these, I could then check for both ::size_t and ::std::size_t. Thanks, Boris
Re: Traversing typedef hierarchy in C/C++ tree
On 20 April 2011 10:10, Boris Kolpackov wrote:
>
>> What about std::size_t?
>
> This one is actually covered. In GCC AST std::size_t node is the same
> as ::size_t (i.e., GCC does not create new *_TYPE node for using-
> declarations).
My point is that libstdc++ does not use a using declaration for
std::size_t, in c++config.h there is:
namespace std
{
typedef __SIZE_TYPE__ size_t;
This means std::size_t is a synonym for the same underlying type as
size_t, but in a separate tree.
>> That could be defined as a synonym for __SIZE_TYPE__ or decltype(sizeof(1))
>> so is not in a sequence of typedef declarations that includes size_t.
>
> If it were defined as one of these, I could then check for both ::size_t
> and ::std::size_t.
OK. Sorry I don't know the answer to your question.
page translation
Hi! I'm willing to translate publication located at http://www.gnu.org/software/gcc/egcs-1.1/ to the Belorussian language (my mother tongue). What I'm asking for is your written permission, so you don't mind after I'll post the translation to my blog. The translation is intended only for web, no print copies planned. Visitors of your website, who come from Minsk (Belorussia) will be the ones, who will read this blogpost, that's the only way to spread them, no additional instruments we can use. Every translation we ever do does not costs a penny for the webpage, which is translated. All we ask is to link back in whatever way you feel confident about it. Thank you for the article. You can leave a voice message and I will call you back, if you prefer a call instead of emails. Sincerely, Bohdan Zograf +(360) 488-0303
Re: Traversing typedef hierarchy in C/C++ tree
Boris Kolpackov writes:
> I am trying to figure out how to get a typedef hierarchy from the C/C++
> tree in GCC. Consider the following declarations:
>
> struct s {};
>
> typedef s s_t;
> typedef s_t my_s_t;
>
> my_s_t x;
>
> Giveb 'x' VAR_DECL I can have this traversal using TYPE_MAIN_VARIANT():
>
> x -> my_s_t -> s;
>
> What I am trying to achieve is this:
>
> x -> my_s_t -> s_t -> s
>
> I looked at TYPE_NEXT_VARIANT(), but this is a list while what I need
> is a tree (hierarchy).
But there is no heirarchy in your example. There is only a list.
> Some background on why I need this: I would like to determine if a
> member of a class is size_t so that I can always map it to a 64-bit
> integer in another system (RDBMS). In other words:
>
> struct s
> {
> unsigned int i;// -> 32-bit int
> size_t s; // -> 64-bit int
> }
>
> Even though size_t might be typedef'ed as unsigned int. In the above
> example I can do it. However, adding a level or indirections causes
> problems:
>
> typedef size_t my_size;
>
> struct s
> {
> my_size s; // TYPE_MAIN_VARIANT(my_size) == unsigned int
> }
>
> Any ideas will be much appreciated.
As far as I know this is not possible. A typedef name is just an alias
for the underlying type. When you typedef T as TNAME, where T is itself
a typedef, GCC records that TNAME is a name for the underlying type of
T. It does not record an equivalence of T and TNAME. The C/C++
language do not require GCC to keep track of this information, and it's
simpler for the frontend to just maintain a list.
Ian
Re: unreferenced main in embedded source code
domenico margiotta writes: > i'm programming for embedded system and for work i use a code warrior > ide (for freescale microprocessor). > > Our client has required to clean every warning in souce code. The > codewarrior compiler don't detect every warning and so the client said > to use a gcc -Wall and lint command. > > In our source code,we don't use a classic main(), but we specified at > the IDE how is the main() and it compile fine, but when i run gcc > -Wall, i reached the error for "undefined reference to `main' ". > > Is it possible specify my entry point as main()? This question is not appropriate for the mailing list gcc@gcc.gnu.org, which is for GCC developers. It would be appropriate for the mailing list gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. The compiler doesn't really care about main. This is more of a linker issue. If you are just looking for compilation time warnings, and you are doing the actual compilation with a different compiler, then I wouldn't worry about this. In general, the way to specify the entry point for your program is to use the linker option -e, typically via -Wl,-e,mymain. You will probably also need to use the -nostartfiles option. See the docs for those options (see the linker docs for -e). Ian
Re: page translation
Bohdan Zograf writes: > I'm willing to translate publication located at > http://www.gnu.org/software/gcc/egcs-1.1/ to the Belorussian language > (my mother tongue). What I'm asking for is your written permission, so > you don't mind after I'll post the translation to my blog. The > translation is intended only for web, no print copies planned. > Visitors of your website, who come from Minsk (Belorussia) will be the > ones, who will read this blogpost, that's the only way to spread them, > no additional instruments we can use. Every translation we ever do > does not costs a penny for the webpage, which is translated. All we > ask is to link back in whatever way you feel confident about it. Please never send messages to both gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org. This message would be fine on either list, but not both. Thanks. That is a very old web page and that information it contains is not useful to anybody. I don't recommend taking the time to translate it. However, in general I think you should feel free to translate any of the web pages on http://gcc.gnu.org as long as your translation links back to the original. Ian
Re: Traversing typedef hierarchy in C/C++ tree
Hi Ian, Ian Lance Taylor writes: > As far as I know this is not possible. A typedef name is just an alias > for the underlying type. When you typedef T as TNAME, where T is itself > a typedef, GCC records that TNAME is a name for the underlying type of > T. It does not record an equivalence of T and TNAME. The C/C++ > language do not require GCC to keep track of this information, and it's > simpler for the frontend to just maintain a list. Yes, that's what I suspect. Which is unfortunate since GCC already creates all the nodes. All that is left is to establish a link between two types. While this is not necessary for C/C++ compilation, it could be useful for other tools that can now be built with the GCC plugin architecture. Thanks, Boris
Re: Traversing typedef hierarchy in C/C++ tree
Boris Kolpackov writes: > Ian Lance Taylor writes: > >> As far as I know this is not possible. A typedef name is just an alias >> for the underlying type. When you typedef T as TNAME, where T is itself >> a typedef, GCC records that TNAME is a name for the underlying type of >> T. It does not record an equivalence of T and TNAME. The C/C++ >> language do not require GCC to keep track of this information, and it's >> simpler for the frontend to just maintain a list. > > Yes, that's what I suspect. Which is unfortunate since GCC already creates > all the nodes. All that is left is to establish a link between two types. > While this is not necessary for C/C++ compilation, it could be useful for > other tools that can now be built with the GCC plugin architecture. If you can make that work without using any extra memory and without making it more expensive to handle typedefs, I expect that the patch would be acceptable. Ian
Re: Broken LTO bootstrtap for more than a month
On 04/20/2011 03:16 AM, Jan Hubicka wrote: On Tue, Apr 19, 2011 at 7:01 AM, Richard Guenther I have been doing LTO bootstrap and reporting failures. The current LTO bootstrap failure us http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48671 This is FDO problem, not LTO problem and should be fixed now. Honza Perhaps more kinds of LTO bootstraps are needed. I can squeeze what I did here: http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg01900.html between the 18 UTC and 00 UTC run of the weather model (it needs about 1 hour 45 minutes) [ between 0:20 and 2:05 UTC daily ]. It only tests C and Fortran, but those are the most tested frontends anyway (/snark) [ counting tests in the Summary list ] -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
GCC 4.4/4.6/4.7 uninitialized warning regression?
On Wed, Apr 20, 2011 at 11:22 AM, Cary Coutant wrote:
>> This caused:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12689
>
> I've committed the following to fix this. Thanks!
>
> -cary
>
> PR gold/12689
> * archive.h (Incremental_archive_entry::Archive_member):
> Initialize arg_serial_ (second constructor).
>
> Index: archive.h
> ===
> RCS file: /cvs/src/src/gold/archive.h,v
> retrieving revision 1.35
> diff -u -p -r1.35 archive.h
> --- archive.h 12 Apr 2011 00:44:47 - 1.35
> +++ archive.h 20 Apr 2011 18:15:38 -
> @@ -51,7 +51,7 @@ struct Archive_member
> : obj_(NULL), sd_(NULL), arg_serial_(0)
> { }
> Archive_member(Object* obj, Read_symbols_data* sd)
> - : obj_(obj), sd_(sd)
> + : obj_(obj), sd_(sd), arg_serial_(0)
> { }
> // The object file.
> Object* obj_;
>
This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it?
Why doesn't 64bit GCC 4.2 warn it?
--
H.J.
Re: Name lookup problem.
[ Adding Jason and gcc@ ]
Jason,
On Tue, Apr 19, 2011 at 22:10, Lawrence Crowl wrote:
> For the testcase x1hardlookup.cc, we read in the following from
> the pph file.
>
> namespace :: {
> function_decl int (int, struct D) operator+
> type_decl struct D D
> var_decl int V
> type_decl struct V V
> namespace N {
> var_decl int x
> var_decl struct V w
> function_decl int (int) I
> var_decl struct C O
> function_decl int (int, struct C) operator+
> type_decl struct C C
> var_decl int V
> }
> }
>
> Then we walk though the global namespace doing
> pushdecl_with_scope (t, level, /*is_friend=*/false);
> for each symbol in it.
> I added recursion, so that nested namespaces get the same treatment.
>
> pushdecl operator+ onto scope ::
> pushdecl D onto scope ::
> pushdecl V onto scope ::
> pushdecl V onto scope ::
> pushdecl x onto scope N
> pushdecl w onto scope N
> pushdecl I onto scope N
> pushdecl O onto scope N
> pushdecl operator+ onto scope N
>
> Looks right, but...
>
> x1hardlookup.cc:1:0: error: declaration of
> 'int N::operator+(int, N::C)'
> x1hardlookup.h:17:5: error: conflicts with previous declaration
> 'int operator+(int, D)'
>
> So, somehow it says it's pushing to scope N,
> but really it seems to be pushing to scope ::.
> The same happens again.
>
> pushdecl C onto scope N
> pushdecl V onto scope N
> x1hardlookup.cc:1:0: error: declaration of
> 'int N::V'
> x1hardlookup.h:15:5: error: conflicts with previous declaration
> 'int V'
>
> Any ideas on what context we're supposed to be changing to get it
> to actually push the decl into the right scope?
>
I don't know. I thought pushdecl_with_scope would be it. Jason, is
there any other bookkeeping routine we would need to be calling?
Maybe we need to set some global that points to the current namespace
before calling pushdecl_with_scope()? There is a 'current_namespace'
definition in cp-tree.h. Maybe that needs to be setup?
The way I debugged these problems is to set a breakpoint at the
error() call and backtrack from there to see which lookup routine took
the wrong turn.
Thanks. Diego.
Re: Name lookup problem.
On 04/20/2011 11:38 AM, Diego Novillo wrote: I don't know. I thought pushdecl_with_scope would be it. Jason, is there any other bookkeeping routine we would need to be calling? Maybe we need to set some global that points to the current namespace before calling pushdecl_with_scope()? There is a 'current_namespace' definition in cp-tree.h. Maybe that needs to be setup? Hmm, seems that way. SET_IDENTIFIER_NAMESPACE_VALUE uses current_namespace rather than current_binding_level. Jason
Re: GCC 4.4/4.6/4.7 uninitialized warning regression?
> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it? > Why doesn't 64bit GCC 4.2 warn it? Good question. It seems that the difference is whether the compiler generates a field-by-field copy or a call to memcpy(). According to David, the trunk gcc in 32-bit mode doesn't call memcpy, but still doesn't warn. He's looking at it. -cary
Re: GCC 4.4/4.6/4.7 uninitialized warning regression?
On Wed, Apr 20, 2011 at 12:03 PM, Cary Coutant wrote: >> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it? >> Why doesn't 64bit GCC 4.2 warn it? > > Good question. It seems that the difference is whether the compiler > generates a field-by-field copy or a call to memcpy(). According to > David, the trunk gcc in 32-bit mode doesn't call memcpy, but still > doesn't warn. He's looking at it. It seems to be related to alias rewrite -- the use of single memory token somehow blocks the warning (even though the struct read are SRAed). David > > -cary >
[pph] Merge rev 172663 from trunk
The previous merge broke release checking builds because of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48652. That was fixed in the very next rev after my merge, so I just cherry picked rev 172663. Lawrence, this should fix your builds. Diego.
Re: GCC 4.4/4.6/4.7 uninitialized warning regression?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/11 13:06, Xinliang David Li wrote: > On Wed, Apr 20, 2011 at 12:03 PM, Cary Coutant wrote: >>> This brings out 2 questions. Why don't GCC 4.4/4.6/4.7 warn it? >>> Why doesn't 64bit GCC 4.2 warn it? >> >> Good question. It seems that the difference is whether the compiler >> generates a field-by-field copy or a call to memcpy(). According to >> David, the trunk gcc in 32-bit mode doesn't call memcpy, but still >> doesn't warn. He's looking at it. > > It seems to be related to alias rewrite -- the use of single memory > token somehow blocks the warning (even though the struct read are > SRAed). You can end up tripping over all kinds of things. In fact, I found myself today looking at this for -Warray-bounds: # BLOCK 11 freq:4946 # PRED: 9 [50.0%] (false,exec) 10 [100.0%] (fallthru,exec) 8 [28.0%] (false,exec) Invalid sum of incoming frequencies 2819, should be 4946 # D.39048_1 = PHI <3(9), D.39048_19(10), 4294967295(8)> # VUSE <.MEM_38(D)> D.39016_24 = default_target_hard_regs.x_fixed_regs[D.39048_1]; Note the value of D.39041_1 if we enter through block #8. We get no warning. Now one of my local patches happens to isolate the path which includes the edge 8->11 creating this block: # BLOCK 18 # PRED: 8 [28.0%] (false,exec) Invalid sum of incoming frequencies 692, should be 0 # VUSE <.MEM_39(D)> D.38986_52 = default_target_hard_regs.x_fixed_regs[4294967295]; Which (of course) triggers the -Warray-bounds warning. Whee fun, optimize better and expose a warning. As it turns out the path including 8->11 is unexecutable, but to expose that we're really going to have to tackle path isolation in a real way rather than the ad-hoc stuff done by the jump threader right now. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNr2X8AAoJEBRtltQi2kC7Bo8H/0Le7ZdG8Fi/XMRPqbc3oiF/ A8zipmNXNdw29JTH488GJR4BtAuhidiw1EmdUBgj4UxhNXVvHkF+zJBEnzh/6oS5 exY9qTU0/hY6eW4UsdefQPczu1Uy/CSJgs9jFzZjLku6ao6EudOdiE5xXS6xc4Iq K2epQkMLFigc05W7TNGWNFC+r6Ty6OlS1xz8IIUOunjBwTax4QWQknAy5YDvXiF+ yJCTvattorNxgCEYizG+sVCo0/wNtZB0s2V/TDCdOWeOsZI2/yWC8+QKGcacnZRQ L2vGQkq7fHScNxsLrxSGbnCj72W9StM/eSYU9ABfMl4KLcq2miuy7JXEz3qDlok= =LO3d -END PGP SIGNATURE-
