public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Larry Evans <cppljevans@suddenlink.net>
To: gcc@gcc.gnu.org
Subject: Re: Is there a recursive debug_c_tree which decodes "variant tag"?
Date: Thu, 28 May 2009 21:06:00 -0000	[thread overview]
Message-ID: <gvmnis$kae$1@ger.gmane.org> (raw)
In-Reply-To: <m363flmb6g.fsf@google.com>

On 05/28/09 11:42, Ian Lance Taylor wrote:
 > Larry Evans <cppljevans@suddenlink.net> writes:
 >
 >> While attempting to debug the compiler on:
 >>
 >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
 >>
 >> I'm having great difficulty understanding the output
 >> of debug_c_tree or debug_tree because the child
 >> tree's are not shown.
 >
 > Can you give an example of what you mean?  debug_tree does show child
 > trees as I understand it, although at each level down it shows less
 > information.  If you want more information about a particular child,
 > then you can see the address in the shortened information, and you can
 > call debug_tree on that address.

Thanks Ian.  That helped.

 >
 >> Is there any such debug_tree function usable in
 >> gdb or ddd which will show the actual tree
 >> variant?
 >
 > Here again I don't understand what you mean.
 >

 From http://gcc.gnu.org/onlinedocs/gccint-html.tar.gz,
in Tree-overview.html#Tree-overview,
there's this:

   The central data structure used by the internal representation is
   the tree. These nodes, while all of the C type tree, are of many
   varieties. A tree is a pointer type, but the object to which it
   points may be of a variety of types.

A tree variant means one of these tree "varieties" mentioned in the
above quote.  I'm guessing the value returned by macro, TREE_CODE, is
some tag indicating which variety of tree.  What I meant by "show the
actual tree variant" is for the print function to decode the tag and
just print the particular variant for that tag.  However, I guess
decode_tree does that, but just prints the address of the child trees.
The user must manually call debug_tree on those children to see what
type they are.

I've tried that but it's not helping much.  The compiler is trying to
expand the pack expansion:

       integral_c
       < Integral
       , Values
       >...

in this template:

   template<typename Integral, Integral... Values>
   struct package_c
   : package
     < integral_c
       < Integral
       , Values
       >...
     >
   {
   };


at this instance:

      typedef
     package_c< int, 1,2,3>
   ints_type
   ;

where:

   template<typename Integral, Integral Value>
   struct integral_c
   {};

That works except when this is present:

     template
     < typename Package_C
     >
   struct impl_front
   ;
     template
     < typename Integral
     , Integral Head
     , Integral... Tail
     >
   struct impl_front
     < package_c
       < Integral
       , Head
       , Tail...
       >
     >
   {
           typedef
         integral_c<Integral,Head>
       type
       ;
   };


So, I'm trying to see what the tree looks like.  AFAICT, the tree
should, somehow, reflect a pattern expansion:

   integral_c<Integral,Values>

and I was hoping, somehow, to see that or some error by using
debug_tree.  I expected to see a tree with children
representing Integral and Values, where Values was
a parameter pack. However, all I get at:

Breakpoint 3, make_pack_expansion (arg=0x7f62797cfe40) at 
<gccsrc>/gcc/cp/pt.c:2692

is the following:

(gdb) p arg
$1 = (tree) 0x7f62797cfe40
(gdb) pt arg
  <record_type 0x7f62797cfe40 integral_c type_5 VOID
     align 8 symtab 0 alias set -1 canonical type 0x7f62797c4cc0 context 
<namespace_decl 0x7f62797c4a80 expbug>
     no-binfo use_template=1 interface-unknown
     chain <type_decl 0x7f62797cff00 integral_c>>

Then, using the call debug_tree on some addression shown above:

(gdb) call debug_tree(0x7f62797cff00)
  <type_decl 0x7f62797cff00 integral_c
     type <record_type 0x7f62797cfe40 integral_c type_5 VOID
         align 8 symtab 0 alias set -1 canonical type 0x7f62797c4cc0 
context <namespace_decl 0x7f62797c4a80 expbug>
         no-binfo use_template=1 interface-unknown
         chain <type_decl 0x7f62797cff00 integral_c>>
     public ignored decl_2 VOID file nested_integral_c_expansion.bug.cpp 
line 20 col 3
     align 1 context <namespace_decl 0x7f62797c4a80 expbug>>

I can't tell from this whether this is an expansion pattern or not.
Further use of call debug_tree on other addresses shown is equally
uninformative :(

I may have to wait till the variadic template experts get around to
this.

Thanks anyway, Ian.

-regards,
Larry



      reply	other threads:[~2009-05-28 19:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-28 18:18 Larry Evans
2009-05-28 18:23 ` Ian Lance Taylor
2009-05-28 21:06   ` Larry Evans [this message]

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='gvmnis$kae$1@ger.gmane.org' \
    --to=cppljevans@suddenlink.net \
    --cc=gcc@gcc.gnu.org \
    /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).