I have need to change gimple dump format

[Sergey Vinogradov]

               I'm a programmer in a Linux Driver Verification project by
ISP RAS. We need the feature, which is almost realized in gcc. However, some
peculiar properties of this feature impend correct and effectively use it.
                    
                    I use gcc with key -fdump-tree-gimple-raw to get gimple
tree dump. Next, I parse this dump (we need assembler-like code for
verification). In the my local copy of gcc 4.3.1 i've corrected the
implementation of the dump and create new key -fdump-tree-gimple-rawp.
                    
                    Since LDV project is intended for a wide range of
software developer and the dump can be useful to other programmers, I would
like to let the developers gcc considered making my own or equivalent to its
implementation in the next gcc release.
                    
                     
                    
                    My code attachment to this e-mail message, but needs to
be verified and formatting.
                    
                    My functions marked with prefix <vinny_> in the file
tree_dump.c.
                    
                    
                    
                    Details.
                    
                    The first. In the dump of string_cst (string constant)
dump string is unescaped and might be truncated. I write function
vinny_fprintf_str (tree-dump.c), which print to dump the escaped string.
This function applied in tree-dump.c in function dequeue_and_dump.
                    
                    String, contains null character had be truncated - this
is incorrect. The strings dump function is rectify.
                    
                    I block dumping strg parameter in the string_cst node if
the string is empty (else strg: lngt: 1 - difficult to difference from the
dump string <lngt: 1>, that happens).
                    
                     
                    
                    Next. I write new constant in the tree-pass.h:
TDF_RAW_VINNY and new key string <rawp>.
                    
                    
                     
                    
                    The third. I write srcp parameter dump in some
expression/statements nodes (by function vinny_dump_location). Earlier this
parameter is not dump in the this nodes. srcp string escaped too.
                    
                     
                    
                    The fourthly. <bitfield> parameter (see c-dump.c) has no
a value part, but it is not effective when parse. The new parameter name is
<bitfield:>.
                    
                     
                    
                    The fifth. In the function_decl is not always dump (i
don't know why) a 'body' parameter (see tree-dump.c, search <FUNCTION_DECL>
string). I rectify this, but I do not know correct whether.
                    
                     
                    
                    The Sixth. In function_decl node (args parameter) is
dump only one first function parameter. I correct it (this is not
necessarily. The order of function parameters and their names can be
obtained from header before first node of function).

                         
                         ------------------------
                  	   ISP RAS, Sergey Vinogradov 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c-dump.c
Type: application/octet-stream
Size: 1552 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080821/59282a1a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tree-dump.c
Type: application/octet-stream
Size: 31413 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080821/59282a1a/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tree-pass.h
Type: application/octet-stream
Size: 20133 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20080821/59282a1a/attachment-0002.obj>