From: Daniel Jacobowitz <drow@mvista.com>
To: gcc-patches@gcc.gnu.org, gdb@sources.redhat.com
Cc: Richard Henderson <rth@redhat.com>
Subject: Re: RFA: Line number fix for prologues
Date: Thu, 22 Jan 2004 18:48:00 -0000 [thread overview]
Message-ID: <20040122184816.GA32235@nevyn.them.org> (raw)
In-Reply-To: <20040116201238.GD26740@redhat.com>
On Fri, Jan 16, 2004 at 12:12:38PM -0800, Richard Henderson wrote:
> On Fri, Jan 16, 2004 at 10:36:01AM -0500, Daniel Jacobowitz wrote:
> > My silly question is, does that emit_nop () even serve any purpose? I
> > imagine it was there to make the loop optimizer happy once upon a time ...
>
> Actually, I think it's for debugging. Certainly the loop optimizer
> won't care one way or the other. If you can show that gdb works as
> well or better without that nop (both dwarf and stabs) then I think
> that's ample reason to remove it.
In that case, this OK for HEAD and 3.4? The only repeatable test
differences were the fixed failures in break.exp/sepdebug.exp that I
mentioned earlier. Tested via the gdb testsuite, dwarf and stabs.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
2004-01-22 Daniel Jacobowitz <drow@mvista.com>
* c-semantics.c (genrtl_while_stmt, genrtl_do_stmt_1)
(genrtl_for_stmt): Remove emit_nop calls.
Index: c-semantics.c
===================================================================
RCS file: /big/fsf/rsync/gcc-cvs/gcc/gcc/c-semantics.c,v
retrieving revision 1.74
diff -u -p -r1.74 c-semantics.c
--- c-semantics.c 24 Nov 2003 20:12:06 -0000 1.74
+++ c-semantics.c 16 Jan 2004 15:27:32 -0000
@@ -430,7 +430,6 @@ genrtl_while_stmt (tree t)
{
tree cond = WHILE_COND (t);
- emit_nop ();
emit_line_note (input_location);
expand_start_loop (1);
genrtl_do_pushlevel ();
@@ -467,7 +466,6 @@ genrtl_do_stmt_1 (tree cond, tree body)
}
else if (integer_nonzerop (cond))
{
- emit_nop ();
emit_line_note (input_location);
expand_start_loop (1);
@@ -478,7 +476,6 @@ genrtl_do_stmt_1 (tree cond, tree body)
}
else
{
- emit_nop ();
emit_line_note (input_location);
expand_start_loop_continue_elsewhere (1);
@@ -542,7 +539,6 @@ genrtl_for_stmt (tree t)
expand_stmt (FOR_INIT_STMT (t));
/* Expand the initialization. */
- emit_nop ();
emit_line_note (input_location);
if (FOR_EXPR (t))
expand_start_loop_continue_elsewhere (1);
next prev parent reply other threads:[~2004-01-22 18:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-16 15:36 Daniel Jacobowitz
2004-01-16 20:12 ` Richard Henderson
2004-01-22 18:48 ` Daniel Jacobowitz [this message]
2004-01-22 20:04 ` Richard Henderson
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=20040122184816.GA32235@nevyn.them.org \
--to=drow@mvista.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb@sources.redhat.com \
--cc=rth@redhat.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