[RFC] dotgen: Generate Graphiviz format .dot dump of functions cfg

[Dennis, CHENG Renquan]

From: Dennis, CHENG Renquan 

The GCC has default support of dumping gimple cfg in vcg format, but when I
was trying to find a tool to interpret the *.006t.vcg dump file, or to generate
a vector image format, it seemed not easy, the vcgviewer [1] not mature as
Graphviz, and Graph::Easy [2] is a perl CPAN module, but why not add a pass
to generate Graphviz .dot format default? These days it seems Graphviz is more
popular;

[1] http://code.google.com/p/vcgviewer/
[2] http://search.cpan.org/~tels/Graph-Easy/

This is a tentative implementation on dumping ".dot" files directly,

I have tested it with gcc-4.5-20100708 snapshot, it works well [*], however,
a feature of the original vcg not implemented,
1) I don't know how to represent the priority information in a .dot file?

[*] the pass->name is "*cfg2dot", means to translate cfg into a dot file, the
name starting with a star is to conform gcc without dump files, because gcc
default pass dump files implementation would always dump a function name line
with ";; Function ..." that is not understood by Graphviz, so I choose to
implement it with dump_register low-level APIs; however, current gcc doesn't
understand plugin registered passes with name starting with a star, it is
better to apply this patch first;
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00912.html

Comments are always welcomed, please give ideas on how this could be more
useful?

If asked, I can also transform this into a patch on gcc for official inclusion,
just changed it from a plugin registered pass to gcc internal pass;

+/* Generate Graphiviz format .dot dump of functions control flow graph,
+   similar as the gcc internal vcg dump.
+   Copyright (C) 2010 by
+   Author: "Dennis, CHENG Renquan" 
---
 Makefile|   26 
 pass-dgen.c |  206 +++
 2 files changed, 232 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
new file mode 100644
index 000..453fbeb
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,26 @@
+
+GCC = gcc
+CC  = gcc
+
+PLUGIN_FILE = dotgen.so
+PLUGIN_SOURCE_FILES = pass-dgen.c
+PLUGIN_OBJECT_FILES = $(patsubst %.c,%.o,$(PLUGIN_SOURCE_FILES))
+
+GCCPLUGINS_DIR := $(shell $(GCC) -print-file-name=plugin)
+CFLAGS += -I$(GCCPLUGINS_DIR)/include -I$(with_gmp)/include -Wall -O2
+
+all: $(PLUGIN_FILE)
+
+$(PLUGIN_FILE): $(PLUGIN_OBJECT_FILES)
+   $(GCC) -shared -o $@ $^
+
+.PHONY: clean all test
+
+test:
+   @if [ ! -d dump-files ]; then mkdir dump-files; fi
+   $(GCC) -fplugin=./$(PLUGIN_FILE) \
+   -fdump-tree-all -dumpdir dump-files/ \
+   -c test1.c
+
+clean:
+   @-rm -f *~ *.o $(PLUGIN_FILE)
diff --git a/pass-dgen.c b/pass-dgen.c
new file mode 100644
index 000..3bf9634
--- /dev/null
+++ b/pass-dgen.c
@@ -0,0 +1,206 @@
+/* Generate Graphiviz format .dot dump of functions control flow graph,
+   similar as the gcc internal vcg dump.
+   Copyright (C) 2010 by
+   Author: "Dennis, CHENG Renquan" 
+
+This software is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+It is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "gcc-plugin.h"
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "tree.h"
+#include "rtl.h"
+#include "basic-block.h"
+#include "function.h"
+#include "langhooks.h"
+#include "tree-flow.h"
+#include "tree-dump.h"
+#include "tree-pass.h"
+
+int plugin_is_GPL_compatible;
+
+static const char *plugin_name;
+static struct plugin_info _version_help_info =
+{
+  "0.1",   /* version */
+  "Dump internal gimple cfg into Graphviz .dot format",
+   /* help */
+};
+
+static void
+gimple_cfg2dot (FILE *file)
+{
+  edge e;
+  edge_iterator ei;
+  basic_block bb;
+  const char *funcname
+= lang_hooks.decl_printable_name (current_function_decl, 2);
+
+  /* Write the file header.  */
+  fprintf (file, "// Function %s\n", funcname);
+  fprintf (file, "digraph graph_%s {\n\n", funcname);
+  fprintf (file, "  graph [ label=%s, labelloc=top ];\n\n", funcname);
+
+  /* Write blocks and edges.  */
+  FOR_EACH_EDGE (e, ei, ENTRY_BLOCK_PTR->succs)
+{
+  fprintf (file, "  ENTRY -> %d", e->dest->index);
+
+  /* how to represent this in Graphviz dot ??? */
+  /* if (e->flags & EDGE_FAKE) */
+  /*   fprintf (file, " linestyle: dotted priority: 10"); */
+  /* else */
+  /*   fprintf (file, " linestyle: solid priority: 100"); */
+
+  fprintf (file, "\n");

ARM GNU/Linux has replaced ARM EABI on primary platform list

[Mark Mitchell]

The Steering Committee has decided to replace arm-eabi with
arm-linux-gnueabi on the primary platform list for GCC 4.6.  That change
reflects the increasing use of ARM cores in GNU/Linux systems and the
fact that it is now relatively easy to obtain such systems.

I've applied the attached patch to reflect that change.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
? htdocs/.#cvs.html.1.178
? htdocs/cvs.html.~1.178.~
? htdocs/develop.html.~1.62.~
? htdocs/index.html.~1.538.~
Index: htdocs/gcc-4.6/criteria.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/criteria.html,v
retrieving revision 1.1
diff -c -5 -p -r1.1 criteria.html
*** htdocs/gcc-4.6/criteria.html6 Apr 2010 11:34:45 -   1.1
--- htdocs/gcc-4.6/criteria.html11 Jul 2010 19:34:59 -
*** application testing.
*** 95,105 
  
  Primary Platform List
  
  The primary platforms are:
  
! arm-eabi
  i386-unknown-freebsd
  i686-pc-linux-gnu
  mipsisa64-elf
  powerpc64-unknown-linux-gnu
  sparc-sun-solaris2.10
--- 95,105 
  
  Primary Platform List
  
  The primary platforms are:
  
! arm-linux-gnueabi
  i386-unknown-freebsd
  i686-pc-linux-gnu
  mipsisa64-elf
  powerpc64-unknown-linux-gnu
  sparc-sun-solaris2.10

gcc-4.3-20100711 is now available

[gccadmin]

Snapshot gcc-4.3-20100711 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100711/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 162061

You'll find:

gcc-4.3-20100711.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20100711.tar.bz2 C front end and core compiler

gcc-ada-4.3-20100711.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20100711.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20100711.tar.bz2  C++ front end and runtime

gcc-java-4.3-20100711.tar.bz2 Java front end and runtime

gcc-objc-4.3-20100711.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20100711.tar.bz2The GCC testsuite

Diffs from 4.3-20100704 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Attributes

[Sean Hunt]

On 07/10/2010 03:56 PM, Ian Lance Taylor wrote:

Sean Hunt  writes:


 void foo () __attribute__((noreturn)); // right per spec
 void foo __attribute__((noreturn)) (); // works
 __attribute__((noreturn)) void foo (); // works

It's obvious that the first example of each kind (noreturn appearing
after the function declarator) must be accepted if it's a GCC
attribute and not if it's a C++0x attributes. The later two (noreturn
appearing before the declaration or after the identifier) must be
accepted for C++0x attributes, but it's not clear if the GCC syntax
being accepted is an accident or by design.


As far as I can see they are both documenated as working at
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Attribute-Syntax.html , so I
think it is by design.


The problem is that it is not clear if that is intended, or merely an 
accident. The spec is rather unclear about a number of things.



Is anyone currently working on C++0x attributes in GCC and, if not, is
there anyone who can help me through what we should and shouldn't
accept in clang?


I don't know the answer to this.  It's clear that C++0x attributes are
not the same as GNU attributes.

Ian


Yes. I'm trying to determine which parts of GCC attributes are merely 
accidents and don't really need implementation, as there are a lot of 
situations where GCC attributes (as implemented) are significantly more 
liberal than C++0x attributes are. This will be an issue that GCC 
developers will encounter when an effort is made to implement 
attributes; I would like to see what discussion can be had before I go 
ahead and reimplement the attribute codepaths within clang.


Sean

Re: GCC4.3.4 downside against GCC3.4.4 on mips?

[Amker.Cheng]

>>>
>>> while GCC3.4.4 treats the long long multiplication just like simple
>>> ones, which generates only one
>>> mult insn for each statement, like
>>>
>>> In my understanding, It‘s not necessary using three mult insn to implement
>>> long long mult, since the operands are converted from int type.
>>
>> This is more helpful.  It is a known case in which GCC 4.x generates worse
>> code.
>
> Should be fixed with 4.6.

Hi, I tested this problem on GCC4.6 snapshot, and it works.
But I could not find the specific patch or record in buglist,
could you help? thanks very much.

-- 
Best Regards.