From: "Dennis, CHENG Renquan" <crquan@fedoraproject.org>
To: basile@starynkevitch.net
Cc: gcc-patches@gcc.gnu.org, Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: [PATCH] passes.c: handle register_pass with a name starting with a star
Date: Sun, 11 Jul 2010 18:14:00 -0000 [thread overview]
Message-ID: <AANLkTin761pMEfFKtKaO6Uqsfvyb1JMcGfJ0aBMe5yjl@mail.gmail.com> (raw)
In-Reply-To: <1278869997.12341.3.camel@glinka>
On Mon, Jul 12, 2010 at 1:39 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Mon, 2010-07-12 at 01:03 +0800, Dennis, CHENG Renquan wrote:
>> The gcc included passes have the feature that a name starting with a start do
>> not dump anything; so should the plugin registered passes have.
>
> I agree with the patch (but I am not authorized to OK it). However, I
> strongly believe that we should specifically document that plugin
> registered passes should have a name, and that a name starting with a
> And I would rather have the plugin pass registration code check that the
> newly inserted plugin pass does have a name, (& probably either a gate
> or an exec function, etc.).
It really already has, inside register_pass (passes.c), the entry for
all plugin registered passes:
void
register_pass (struct register_pass_info *pass_info)
{
bool all_instances, success;
/* The checks below could fail in buggy plugins. Existing GCC
passes should never fail these checks, so we mention plugin in
the messages. */
if (!pass_info->pass)
fatal_error ("plugin cannot register a missing pass");
if (!pass_info->pass->name)
fatal_error ("plugin cannot register an unnamed pass");
If pass doesn't have a name, it would exit with fatal_error;
> star don't have any dump files. AFAIK, nothing is clearly written in
> http://gcc.gnu.org/onlinedocs/gccint/Plugins.html
The real problem should be the documentation, I should have another
patch to document plugin registered pass (passes.texi);
>
> Cheers.
> --
> 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} ***
next prev parent reply other threads:[~2010-07-11 18:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-11 3:47 [PATCH] passes.texi: fill crossref nodes (GCC Internals) crquan
2010-07-11 3:48 ` [PATCH] passes.c: handle register_pass with a name starting with a star crquan
2010-07-11 4:12 ` Dennis, CHENG Renquan
2010-07-11 15:34 ` Dennis, CHENG Renquan
2010-07-11 16:08 ` Andreas Schwab
2010-07-11 17:04 ` Dennis, CHENG Renquan
2010-07-11 17:40 ` Basile Starynkevitch
2010-07-11 18:14 ` Dennis, CHENG Renquan [this message]
2010-07-11 18:17 ` Dennis, CHENG Renquan
2010-07-20 10:21 ` Dennis, CHENG Renquan
2011-04-18 21:35 ` [PATCH] passes.texi: fill crossref nodes (GCC Internals) Gerald Pfeifer
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=AANLkTin761pMEfFKtKaO6Uqsfvyb1JMcGfJ0aBMe5yjl@mail.gmail.com \
--to=crquan@fedoraproject.org \
--cc=basile@starynkevitch.net \
--cc=gcc-patches@gcc.gnu.org \
--cc=schwab@linux-m68k.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).