public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Basile Starynkevitch <basile@starynkevitch.net>
To: Piervit <piervit@pvittet.com>, dnovillo@google.com
Cc: gcc-patches@gcc.gnu.org, richard.guenther@gmail.com
Subject: Re: external declaration of dominance debug functions
Date: Mon, 23 May 2011 20:55:00 -0000	[thread overview]
Message-ID: <20110523201230.03ec2889.basile@starynkevitch.net> (raw)
In-Reply-To: <20110523115632.5abb6956@zenwalk.local>

On Mon, 23 May 2011 11:56:32 +0200
Piervit <piervit@pvittet.com> wrote:

> Le Mon, 23 May 2011 11:30:34 +0200,
> Richard Guenther <richard.guenther@gmail.com> a écrit :
> 
> > On Mon, May 23, 2011 at 10:33 AM, Piervit <piervit@pvittet.com> wrote:
> > > Hello,
> > >
> > > Here is a two lines patch, allowing to use debug_dominance_info and
> > > debug_dominance_tree functions outside of gcc/dominance.c. For the
> > > moment, those functions are not declared in any gcc/*.h files (as
> > > far as I know after trying a grep). I have added them as external
> > > functions into gcc/basic-block.h. I feel this is useful to be able
> > > to call those functions from others files, for exemple from plugins.
> > 
> > debug_* functions are supposed to be used from interactive gdb
> > sessions. They should not be advertised in public headers.
> > 
> > Richard.
> > 
> > > ChangeLog:
> > >
> > > 2011-05-23  Pierre Vittet  <piervit@pvittet.com>
> > >
> > >        * basic-block.h (debug_dominance_info, debug_dominance_tree):
> > >          Add declaration.
> 
> Thank you for your answer. I am sorry I was not aware of this rule.
> However I have try the following command in the gcc/ directory:
> 
> pierre@zenwalk gcc %grep " debug_*" *.h | wc -l
> 231
> 
> And the majority of the result are debug_* functions in header file,
> such as extern void debug_tree (tree); in tree.h, extern void
> debug_pass (void); in tree-pass.h and many others.

I was expecting Richard Guenther to say no at first to any patch,
especially when it is by a newbie. (Sorry Richie, but you do have your
reputation).   But I would like to hear the position of others (in
particular Diego Novillo, who did long time ago accept a similar patch
from my part).

If really all debug_* functions are only for the ease of gdb, they
should not be declared in public header files and should not be
available to plugins. I believe on the contrary that plugin coders need
much more than experienced GCC hackers some debug help, and that indeed
the existing debug functions are helping them.

So I don't buy Richie's argument. Otherwise, someone would propose a
patch to remove the hundreds of debug_ declarations in public header
files (i.e. those visible to plugins), and if he did, I hope such a
naughty patch won't be accepted.

As I told many many times, debug functions are mostly useful to newbies
and to plugin developers. People (like Richie) working on GCC since the
previous century don't need them. But people working on some plugins
for a few months (or young newbies starting to work on GCC) will be
desperate if these functions vanished. And these debug functions don't
cost at all: they are never called in normal GCC executions! So I don't
understand why declaring in a plugin header an existing debug function
is such an issue.

Hence, as Pierre's GSOC mentor, I told him to perservate on this patch
and I hope it will be accepted some day!!

GCC need more facilities for newbies & plugin developpers, not less!

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

  reply	other threads:[~2011-05-23 18:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-23  9:49 Piervit
2011-05-23  9:56 ` Basile Starynkevitch
2011-05-23 10:22 ` Richard Guenther
2011-05-23 10:53   ` Piervit
2011-05-23 20:55     ` Basile Starynkevitch [this message]
2011-05-23 22:52       ` Richard Guenther
2011-05-23 23:06         ` Nathan Froyd
2011-05-23 23:06           ` Richard Guenther
2011-05-24 10:42         ` Basile Starynkevitch

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=20110523201230.03ec2889.basile@starynkevitch.net \
    --to=basile@starynkevitch.net \
    --cc=dnovillo@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=piervit@pvittet.com \
    --cc=richard.guenther@gmail.com \
    /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).