From: Carlo Wood <carlo@alinoe.com>
To: Richard Henderson <rth@redhat.com>,
gcc@gcc.gnu.org, wilson@specifixinc.com, jason@redhat.com
Subject: Re: RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only.
Date: Tue, 07 Oct 2003 21:12:00 -0000 [thread overview]
Message-ID: <20031007211218.GA11213@alinoe.com> (raw)
In-Reply-To: <20031007194604.GA18217@redhat.com>
On Tue, Oct 07, 2003 at 12:46:04PM -0700, Richard Henderson wrote:
> On Tue, Oct 07, 2003 at 08:32:31PM +0200, Carlo Wood wrote:
> > Next, I manually investigated every place where this happened
> > and either turned off the warning (using TREE_CODE_NOCHECK or
> > with ++nocheck ... --nocheck wraps) and/or added code to handle
> > the EXPR_WITH_FILE_LOCATION.
>
> I think you're completely off-track with this. You'll get
> near 100% false hits with this scheme.
More like 80 - 90%. But its the only sheme that garantees that
you won't miss a hit.
Did you look at the patch? Then you'd see that there are many
places where there *is* a need to add special case handling.
Yes, most hits are for TREE_CODE(t) == SOMETHINGELSE, but you
have to look at those lines before you can see that it says
'SOMETHINGELSE' and not 'CALL_EXPR'.
The huge amount of places where the WFL happily shows up
proves that it is not handled as automatically as you seem
to believe.
Can we now please forget about using WFL? Trust me, the result
would be unmaintainable.
--
Carlo Wood <carlo@alinoe.com>
next prev parent reply other threads:[~2003-10-07 21:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-22 2:31 RFC: debug line info & inlining; patch proposal and request for comments Carlo Wood
2003-09-23 5:33 ` Jim Wilson
2003-09-27 16:38 ` RFA: Adding a location_t (or pointer) to tree_exp for 3.4 only Carlo Wood
2003-10-06 12:58 ` Hans-Peter Nilsson
2003-10-06 17:41 ` Richard Henderson
2003-10-06 17:51 ` Daniel Jacobowitz
2003-10-06 18:03 ` Daniel Berlin
2003-10-06 19:20 ` Carlo Wood
2003-10-06 19:08 ` Carlo Wood
2003-10-06 20:11 ` Richard Henderson
2003-10-06 20:14 ` Daniel Jacobowitz
2003-10-06 20:20 ` Richard Henderson
2003-10-06 20:24 ` Daniel Jacobowitz
2003-10-06 21:54 ` Richard Henderson
2003-10-06 21:53 ` Carlo Wood
2003-10-06 21:55 ` Richard Henderson
2003-10-06 22:30 ` Carlo Wood
2003-10-06 23:17 ` Richard Henderson
2003-10-06 23:49 ` Carlo Wood
2003-10-07 0:07 ` Richard Henderson
2003-10-07 0:43 ` Carlo Wood
2003-10-07 0:46 ` Richard Henderson
2003-10-07 2:40 ` Carlo Wood
2003-10-07 18:32 ` Carlo Wood
2003-10-07 19:08 ` Carlo Wood
2003-10-07 19:46 ` Richard Henderson
2003-10-07 21:12 ` Carlo Wood [this message]
2003-10-07 23:43 ` Carlo Wood
2003-10-07 19:41 ` Carlo Wood
2003-10-12 4:32 ` law
2003-10-12 12:02 ` Daniel Berlin
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=20031007211218.GA11213@alinoe.com \
--to=carlo@alinoe.com \
--cc=gcc@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=rth@redhat.com \
--cc=wilson@specifixinc.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).