It took me quite some time to figure out how to browse the different types of trees that I am interested in. There are still many types and components that I will need later to finish my restrictive exception specification warning mechanic.
I've tried dumping trees but the format of the dumps isn't too useful for learning the underlying format. The standard dump just reformats it as something looking somewhat similar to a C function. The raw dump isn't structured so you have to search for node numbers in order to parse the tree, which makes it very cumbersome. I have just put together some quick generic nested-tree output code and I'm using it to dump some parts of a tree. It is very far from finished as I have to add the different tree-types. I'm working from tree-dump.c:deque_and_dump(). So far it looks like: ===================================================================== func(0x7fffa8e60d00): decl:tree(function_decl). at test/throw.cpp:10. >-DECL_NAME(0x7fffa8e6a1e0): id:tree(identifier_node). | >-IDENTIFIER_POINTER(0x11695b6): foo. | \-IDENTIFIER_LENGTH(0x7fffa8e6a208): 3. | >-DECL_ASSEMBLER_NAME(0x7fffa8e6a960): id:tree(identifier_node). | >-IDENTIFIER_POINTER(0x116960b): _Z3foov. | \-IDENTIFIER_LENGTH(0x7fffa8e6a988): 7. | >-TREE_TYPE(0x7fffa8e6d240): type:tree(function_type). | >-TYPE_MAIN_VARIANT(0x7fffa97d3e40): type:tree(function_type). | | \-TYPE_SIZE(0x7fffa97a87b0): unk:tree(integer_cst). const:tree(integer_cst). const. | | >-int_cst.int_cst.low(0x7fffb1921184): 8. | | >-int_cst.int_cst.high(0x7fffb1921180): 0. | | \-TREE_TYPE(0x7fffa97bb0c0): type:tree(integer_type). | | >-TYPE_NAME(0x7fffa97ca240): id:tree(identifier_node). | | | >-IDENTIFIER_POINTER(0x112e769): bit_size_type. | | | \-IDENTIFIER_LENGTH(0x7fffa97ca268): 13. | | | | | \-TYPE_SIZE(0x7fffa97a8b40): unk:tree(integer_cst). expr:tree(integer_cst). const. | | >-int_cst.int_cst.low(0x7fffb1920e44): 64. | | \-int_cst.int_cst.high(0x7fffb1920e40): 0. | | | \-TYPE_SIZE(0x7fffa97a87b0): unk:tree(integer_cst). const:tree(integer_cst). const. | >-int_cst.int_cst.low(0x7fffb19212b4): 8. | >-int_cst.int_cst.high(0x7fffb19212b0): 0. | \-TREE_TYPE(0x7fffa97bb0c0): type:tree(integer_type). | >-TYPE_NAME(0x7fffa97ca240): id:tree(identifier_node). | | >-IDENTIFIER_POINTER(0x112e769): bit_size_type. | | \-IDENTIFIER_LENGTH(0x7fffa97ca268): 13. | | | \-TYPE_SIZE(0x7fffa97a8b40): unk:tree(integer_cst). const:tree(integer_cst). const. | >-int_cst.int_cst.low(0x7fffb1920f74): 64. | \-int_cst.int_cst.high(0x7fffb1920f70): 0. | \-TREE_CHAIN(0x7fffa8e60c30): ===================================================================== At present it's picking up many things it shouldn't (eg type of a TYPE_SIZE) and discarding many that it should care about (eg func params & statement list), but that's the general format of the dump. I'm guessing it'll average out around 30 dumped lines per code line. I'm currently getting it to dump inside -fdump-tree-original to that dump's target file (which dumps once per function), but it can be called anywhere on any tree. Do you think this would be useful to people (especially beginners)? It would certainly have been useful to me, and the tree structure documentation is unfinished. It would probably be useful as it's own dump entry, say -fdump-tree-original-nodetree or something.
