This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
Re: 10 GCC regressions, 8 new, with your patch on 2001-07-16T22:08:55Z.
- To: Daniel Berlin <dan at cgsoftware dot com>, gcc-patches at gcc dot gnu dot org
- Subject: Re: 10 GCC regressions, 8 new, with your patch on 2001-07-16T22:08:55Z.
- From: Jan Hubicka <jh at suse dot cz>
- Date: Tue, 17 Jul 2001 14:33:32 +0200
- Cc: gcc-regression at gcc dot gnu dot org, jh at suse dot cz
- References: <200107170121.f6H1Lop04174@maat.cygnus.com> <874rsc475r.fsf@cgsoftware.com>
> "GCC regression checker" <regress@maat.cygnus.com> writes:
>
> > With your recent patch, GCC has some regression test failures, which
> > used to pass. There are 8 new failures, and 2
> > failures that existed before and after that patch; 0 failures
> > have been fixed.
> >
> > The new failures are:
> > powerpc-eabisim gcc.sum gcc.c-torture/execute/920501-7.c
> > powerpc-eabisim gcc.sum gcc.c-torture/execute/comp-goto-2.c
> > powerpc-eabisim gcc.sum gcc.dg/20000707-1.c
> > powerpc-eabisim gcc.sum gcc.dg/unused-2.c
> > native gcc.sum gcc.c-torture/execute/920501-7.c
> > native gcc.sum gcc.c-torture/execute/comp-goto-2.c
> > native gcc.sum gcc.dg/20000707-1.c
> > native gcc.sum gcc.dg/unused-2.c
>
> Jan, these look like they might have been affected by the unneeded
> code labels, PRE doesn't even touch the code for at least , so
> it's not a load motion problem. :)
They seems to be, maybe result of combination of the patches, as
I didn't get these during the validating build before installing.
BTW I didn't received the warning email, it seems to be because
you've inserted the changelog entry at the end, so it confused
the script. Thanks for letting me know.
Hi,
I've finally suceeded to reproduce the failure on modified testcase:
x(a)
{
__label__ xlab;
void y(a)
{
if (a==0)
goto xlab;
y (a-1);
}
y (a);
xlab:;
return a;
}
main ()
{
if (x (1000) != 1000)
abort ();
exit (0);
}
The problem is nonlocal label xlab, that gets no edges in the CFG
so the code decides to remove it. The note than starts to flow
fluently in the insn stream occasionally making jump to it to
over at wrong location. This happends just in very specific cases,
where scheduling happends to mess thinks up, thats why it didn't
reproduced on my i586 tree.
All new failures seems to have the nonlocal labels in common,
so I hope that the patch solves them all.
Regtested/bootstrapped i686
Honza
Tue Jul 17 14:25:29 CEST 2001 Jan Hubicka <jh@suse.cz>
* flow.c (try_optimize_cfg): Avoid removal of labels
with LABEL_PRESERVE_P set.
Index: flow.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/flow.c,v
retrieving revision 1.429
diff -c -3 -p -r1.429 flow.c
*** flow.c 2001/07/17 04:55:23 1.429
--- flow.c 2001/07/17 12:25:08
*************** try_optimize_cfg (mode)
*** 3709,3714 ****
--- 3710,3716 ----
&& GET_CODE (b->head) == CODE_LABEL
/* If previous block does end with condjump jumping to next BB,
we can't delete the label. */
+ && !LABEL_PRESERVE_P (b->head)
&& (b->pred->src == ENTRY_BLOCK_PTR
|| !reg_mentioned_p (b->head, b->pred->src->end)))
{
*************** try_optimize_cfg (mode)
*** 3725,3730 ****
--- 3727,3734 ----
&& s->succ_next == NULL
&& (s->flags & EDGE_EH) == 0
&& (c = s->dest) != EXIT_BLOCK_PTR
+ && (GET_CODE (c->head) != CODE_LABEL
+ || !LABEL_PRESERVE_P (c->head))
&& c->pred->pred_next == NULL
/* If the jump insn has side effects,
we can't kill the edge. */