Re: none

Re: none

[Andreas Jaeger]

law@redhat.com writes:

> Your recent patch to toplev.c is causing regressions on the x86.  
> Specifically the compiler is hanging in c-torture on 
> compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
>
> Please investigate and fix:
>
> 2002-01-04  H.J. Lu <hjl@gnu.org>
>
>         * toplev.c (rest_of_compilation): Fix a typo when calling
>         cleanup_cfg.

In that case we have a latent bug.  I build the testsuite on x86
without problems (but have store motion disabled).

I'm appending the patch again, it's really obvious IMO and I expect
the problem to be somewhere else.

Honza, do you have any idea?

Andreas


Index: toplev.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/toplev.c,v
retrieving revision 1.564
retrieving revision 1.565
diff -u -r1.564 -r1.565
--- toplev.c	2001/12/27 17:22:00	1.564
+++ toplev.c	2002/01/04 05:41:24	1.565
@@ -1,6 +1,6 @@
 /* Top level of GNU C compiler
    Copyright (C) 1987, 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-   1999, 2000, 2001 Free Software Foundation, Inc.
+   1999, 2000, 2001, 2002 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -2941,7 +2941,7 @@
   open_dump_file (DFI_cfg, decl);
 
   find_basic_blocks (insns, max_reg_num (), rtl_dump_file);
-  cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0
+  cleanup_cfg ((optimize ? CLEANUP_EXPENSIVE : 0)
 	       | (flag_thread_jumps ? CLEANUP_THREADING : 0));
   check_function_return_warnings ();
 


-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html

[H . J . Lu]

On Fri, Jan 04, 2002 at 07:40:17PM +0100, Andreas Jaeger wrote:
> law@redhat.com writes:
> 
> > Your recent patch to toplev.c is causing regressions on the x86.  
> > Specifically the compiler is hanging in c-torture on 
> > compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
> >
> > Please investigate and fix:
> >
> > 2002-01-04  H.J. Lu <hjl@gnu.org>
> >
> >         * toplev.c (rest_of_compilation): Fix a typo when calling
> >         cleanup_cfg.
> 
> In that case we have a latent bug.  I build the testsuite on x86
> without problems (but have store motion disabled).
> 
> I'm appending the patch again, it's really obvious IMO and I expect
> the problem to be somewhere else.
> 
> Honza, do you have any idea?
> 

I believe

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html

is broken if you ask me.


H.J.

Re: none

[law]

  > In that case we have a latent bug.  I build the testsuite on x86
  > without problems (but have store motion disabled).
I suspect we have a latent bug too.

jeff

Re: none

[Jan Hubicka]

>   > In that case we have a latent bug.  I build the testsuite on x86
>   > without problems (but have store motion disabled).
> I suspect we have a latent bug too.
It should be fixed by patch I sent to "bad jump threading change" thread.
Hope to see the other MIPS problem resolved now (I am no more seeing the
misscomparison on file I seen before, but the bootstrap run out of disc
space and daemon has killed my tree from /tmp... uh oh.

Honza
> 
> jeff

Re: your mail

[H . J . Lu]

On Fri, Jan 04, 2002 at 11:30:56AM -0700, law@redhat.com wrote:
> 
> Your recent patch to toplev.c is causing regressions on the x86.  
> Specifically the compiler is hanging in c-torture on 
> compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
> 
> Please investigate and fix:
> 
> 2002-01-04  H.J. Lu <hjl@gnu.org>
> 
>         * toplev.c (rest_of_compilation): Fix a typo when calling
>         cleanup_cfg.

My patch fixed a typo in

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html

which caused the bootstrap failure on mips. I guess my change exposed
the bug on x86. I believe that patch is broken and should be reverted
for 3.1 if we can't fix it soon.


H.J.

Bad jump threading change.

[H . J . Lu]

On Fri, Jan 04, 2002 at 11:30:56AM -0700, law@redhat.com wrote:
> 
> Your recent patch to toplev.c is causing regressions on the x86.  
> Specifically the compiler is hanging in c-torture on 
> compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
> 
> Please investigate and fix:
> 
> 2002-01-04  H.J. Lu <hjl@gnu.org>
> 
>         * toplev.c (rest_of_compilation): Fix a typo when calling
>         cleanup_cfg.
> 

Here is a simpler testcase:

--foo.c--
void
foo (int i)
{
  while (i == 0) ;
}
----

"-funroll-all-loops -O2" goes into an infinite loop. May I suggest
backing out

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html


H.J.

Re: Bad jump threading change.

[Jan Hubicka]

> On Fri, Jan 04, 2002 at 11:30:56AM -0700, law@redhat.com wrote:
> > 
> > Your recent patch to toplev.c is causing regressions on the x86.  
> > Specifically the compiler is hanging in c-torture on 
> > compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
> > 
> > Please investigate and fix:
> > 
> > 2002-01-04  H.J. Lu <hjl@gnu.org>
> > 
> >         * toplev.c (rest_of_compilation): Fix a typo when calling
> >         cleanup_cfg.
> > 
> 
> Here is a simpler testcase:
> 
> --foo.c--
> void
> foo (int i)
> {
>   while (i == 0) ;
> }
> ----
> 
> "-funroll-all-loops -O2" goes into an infinite loop. May I suggest
> backing out
> 
> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
I probably do have proper fix, so I will send the patch once testing finishes.

Honza
> 
> 
> H.J.

Re: Bad jump threading change.

[H . J . Lu]

On Fri, Jan 04, 2002 at 10:14:06PM +0100, Jan Hubicka wrote:
> > On Fri, Jan 04, 2002 at 11:30:56AM -0700, law@redhat.com wrote:
> > > 
> > > Your recent patch to toplev.c is causing regressions on the x86.  
> > > Specifically the compiler is hanging in c-torture on 
> > > compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
> > > 
> > > Please investigate and fix:
> > > 
> > > 2002-01-04  H.J. Lu <hjl@gnu.org>
> > > 
> > >         * toplev.c (rest_of_compilation): Fix a typo when calling
> > >         cleanup_cfg.
> > > 
> > 
> > Here is a simpler testcase:
> > 
> > --foo.c--
> > void
> > foo (int i)
> > {
> >   while (i == 0) ;
> > }
> > ----
> > 
> > "-funroll-all-loops -O2" goes into an infinite loop. May I suggest
> > backing out
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
> I probably do have proper fix, so I will send the patch once testing finishes.

Does it also fix mips? If mips is still broken and won't be fixed for
3.1, I think that patch should be reverted.


H.J.

Re: Bad jump threading change.

[Jan Hubicka]

> On Fri, Jan 04, 2002 at 10:14:06PM +0100, Jan Hubicka wrote:
> > > On Fri, Jan 04, 2002 at 11:30:56AM -0700, law@redhat.com wrote:
> > > > 
> > > > Your recent patch to toplev.c is causing regressions on the x86.  
> > > > Specifically the compiler is hanging in c-torture on 
> > > > compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
> > > > 
> > > > Please investigate and fix:
> > > > 
> > > > 2002-01-04  H.J. Lu <hjl@gnu.org>
> > > > 
> > > >         * toplev.c (rest_of_compilation): Fix a typo when calling
> > > >         cleanup_cfg.
> > > > 
> > > 
> > > Here is a simpler testcase:
> > > 
> > > --foo.c--
> > > void
> > > foo (int i)
> > > {
> > >   while (i == 0) ;
> > > }
> > > ----
> > > 
> > > "-funroll-all-loops -O2" goes into an infinite loop. May I suggest
> > > backing out
> > > 
> > > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
> > I probably do have proper fix, so I will send the patch once testing finishes.
> 
> Does it also fix mips? If mips is still broken and won't be fixed for
> 3.1, I think that patch should be reverted.
Mips is unrealted issue - I can now bootstrap mips CVS with my patch after the
patch got in (from december), but the current CVS still does not bootstrap.  I
am trying to catch the second problem (probably unrelated) today.

I agree that patch should be reverted for 3.1 if I don't suceed fix the
mips till end of weekend. Problem is that old threading code exhibits
bug at m68k and as I remember IA-64 bootstrap too.

Honza
> 
> 
> H.J.

Re: Bad jump threading change.

[Jan Hubicka]

> 
> Does it also fix mips? If mips is still broken and won't be fixed for
> 3.1, I think that patch should be reverted.
> 
I've finally bootstrapped. There are misscomparisons now, but if I revert
changes to 25th december and only install my cfgcleanup fixes it bootstraps
for me fluently, so it is unrelated issue.
I can't do regression tests, as the dejagnu is not present and the
disc space is really limited.

I am looking at it anyway.
Honza
> 
> H.J.

Re: Bad jump threading change.

[H . J . Lu]

On Sat, Jan 05, 2002 at 12:09:11PM +0100, Jan Hubicka wrote:
> > 
> > Does it also fix mips? If mips is still broken and won't be fixed for
> > 3.1, I think that patch should be reverted.
> > 
> I've finally bootstrapped. There are misscomparisons now, but if I revert
> changes to 25th december and only install my cfgcleanup fixes it bootstraps
> for me fluently, so it is unrelated issue.

What did you mean by "25th december"? Did you mean if I do

# ./contrib/gcc_update -D "Dec 25 00:00 PST 2001"
# apply your fixes.

I can bootstrap on mips? What I got are

# ./contrib/gcc_update -D "Dec 17 09:00 PST 2001"

is ok.

# ./contrib/gcc_update -D "Dec 17 09:30 PST 2001"

is bad.

The only relevant change between them is your patch. You should do

# ./contrib/gcc_update -D "Dec 17 09:30 PST 2001"
# apply your fixes.

and make sure you can bootstrap on mips unless you believe your patch
exposes some latent bugs.


H.J.

Re: Bad jump threading change.

[Jan Hubicka]

> On Fri, Jan 04, 2002 at 11:30:56AM -0700, law@redhat.com wrote:
> > 
> > Your recent patch to toplev.c is causing regressions on the x86.  
> > Specifically the compiler is hanging in c-torture on 
> > compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
> > 
> > Please investigate and fix:
> > 
> > 2002-01-04  H.J. Lu <hjl@gnu.org>
> > 
> >         * toplev.c (rest_of_compilation): Fix a typo when calling
> >         cleanup_cfg.
> > 
> 
> Here is a simpler testcase:
> 
> --foo.c--
> void
> foo (int i)
> {
>   while (i == 0) ;
> }
> ----
The problem is caused by empty infinite loop - the jump gets forwarder forever.
THis is the problem for simple branch forwarding too and it is already cared
for in the try_thread_jumps (the infinite loop is detected and threading not done).

WHen implementing threading I decided to limit try_thread_jumps to one threading
at time as I need to save the edges that were threaded and I didn't wanted
to create array for possible multiple edges and thus loops containing more
than two threadable conditionals is not detected.

Here is fix, bootstrapped/regtested i386, OK to install?

(I am now finishing the fix for wide register and tracking down the
MIPS breakage too).


Fri Jan  4 22:39:26 CET 2002  Jan Hubicka  <jh@suse.cz>

	* cfgcleanup.c (try_forward_edges): Allow multiple jump threading.

Index: cfgcleanup.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/cfgcleanup.c,v
retrieving revision 1.18.2.16
diff -c -3 -p -r1.18.2.16 cfgcleanup.c
*** cfgcleanup.c	2002/01/03 21:03:46	1.18.2.16
--- cfgcleanup.c	2002/01/04 21:39:16
*************** try_forward_edges (mode, b)
*** 346,352 ****
       int mode;
  {
    bool changed = false;
!   edge e, next, threaded_edge;
  
    for (e = b->succ; e; e = next)
      {
--- 346,353 ----
       int mode;
  {
    bool changed = false;
!   edge e, next, *threaded_edges = NULL;
!   int nthreaded_edges = 0;
  
    for (e = b->succ; e; e = next)
      {
*************** try_forward_edges (mode, b)
*** 383,395 ****
  
  	  /* Allow to thread only over one edge at time to simplify updating
  	     of probabilities.  */
! 	  else if ((mode & CLEANUP_THREADING) && !threaded)
  	    {
! 	      threaded_edge = thread_jump (mode, e, target);
! 	      if (threaded_edge)
  		{
! 		  new_target = threaded_edge->dest;
  		  new_target_threaded = true;
  		}
  	    }
  
--- 384,400 ----
  
  	  /* Allow to thread only over one edge at time to simplify updating
  	     of probabilities.  */
! 	  else if (mode & CLEANUP_THREADING)
  	    {
! 	      edge t = thread_jump (mode, e, target);
! 	      if (t)
  		{
! 		  new_target = t->dest;
  		  new_target_threaded = true;
+ 		  if (!nthreaded_edges)
+ 		    threaded_edges = xmalloc (sizeof (*threaded_edges)
+ 					      * n_basic_blocks);
+ 		  threaded_edges[nthreaded_edges++] = t;
  		}
  	    }
  
*************** try_forward_edges (mode, b)
*** 439,444 ****
--- 444,450 ----
  	  gcov_type edge_count = e->count;
  	  int edge_probability = e->probability;
  	  int edge_frequency;
+ 	  int n = 0;
  
  	  if (threaded)
  	    {
*************** try_forward_edges (mode, b)
*** 480,486 ****
  	      if (first->frequency < 0)
  		first->frequency = 0;
  	      if (first->succ->succ_next)
! 		t = threaded_edge;
  	      else
  		t = first->succ;
  
--- 486,492 ----
  	      if (first->frequency < 0)
  		first->frequency = 0;
  	      if (first->succ->succ_next)
! 		t = threaded_edges [n++];
  	      else
  		t = first->succ;
  
*************** try_forward_edges (mode, b)
*** 492,497 ****
--- 498,505 ----
  	}
      }
  
+   if (threaded_edges)
+     free (threaded_edges);
    return changed;
  }
  \f

Re: Bad jump threading change.

[Richard Henderson]

On Fri, Jan 04, 2002 at 10:42:10PM +0100, Jan Hubicka wrote:
> 	* cfgcleanup.c (try_forward_edges): Allow multiple jump threading.

Ok.


r~

Jump threading fix

[Jan Hubicka]

Hi,
I finally got where the problem is.  Instead of marking destimation of set
as clobbered, I am marking the source. No wonder that it goes wrong.

This makes the problem to go out of MIPS testcase and bootstrapped+regtested
i386.  MIPS bootstrap is still in progress but I am installing the patch
as obvious as the code needs to be fixed anyway.

The patch also fixes potential probles in handling hard registers and adds
proper checking of parallels containing both conditional and side effect
expression.

Honza

Sat Jan  5 00:44:08 CET 2002  Jan Hubicka  <jh@suse.cz.
	* Makefile.in (cfgcleanup.o): Add dependency on tm_p.h
	* cfgcleanup.c: Include tm_p.h
	(mark_effect): Fix handling of hard register; fix handling of SET
Index: cfgcleanup.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/cfgcleanup.c,v
retrieving revision 1.29
diff -c -3 -p -r1.29 cfgcleanup.c
*** cfgcleanup.c	2001/12/30 12:20:42	1.29
--- cfgcleanup.c	2002/01/04 23:00:28
*************** Software Foundation, 59 Temple Place - S
*** 43,48 ****
--- 43,49 ----
  #include "recog.h"
  #include "toplev.h"
  #include "cselib.h"
+ #include "tm_p.h"
  
  #include "obstack.h"
  
*************** mark_effect (exp, nonequal)
*** 192,212 ****
    rtx exp;
    regset nonequal;
  {
    switch (GET_CODE (exp))
      {
        /* In case we do clobber the register, mark it as equal, as we know the
           value is dead so it don't have to match.  */
        case CLOBBER:
  	if (REG_P (XEXP (exp, 0)))
! 	  CLEAR_REGNO_REG_SET (nonequal, REGNO (XEXP (exp, 0)));
  	return false;
  
        case SET:
  	if (rtx_equal_for_cselib_p (SET_DEST (exp), SET_SRC (exp)))
  	  return false;
! 	if (GET_CODE (SET_SRC (exp)) != REG)
  	  return true;
! 	SET_REGNO_REG_SET (nonequal, REGNO (SET_SRC (exp)));
  	return false;
  
        default:
--- 193,235 ----
    rtx exp;
    regset nonequal;
  {
+   int regno;
+   rtx dest;
    switch (GET_CODE (exp))
      {
        /* In case we do clobber the register, mark it as equal, as we know the
           value is dead so it don't have to match.  */
        case CLOBBER:
  	if (REG_P (XEXP (exp, 0)))
! 	  {
! 	    dest = XEXP (exp, 0);
! 	    regno = REGNO (dest);
! 	    CLEAR_REGNO_REG_SET (nonequal, regno);
! 	    if (regno < FIRST_PSEUDO_REGISTER)
! 	      {
! 		int n = HARD_REGNO_NREGS (regno, GET_MODE (dest));
! 		while (--n > 0)
! 		  CLEAR_REGNO_REG_SET (nonequal, regno + n);
! 	      }
! 	  }
  	return false;
  
        case SET:
  	if (rtx_equal_for_cselib_p (SET_DEST (exp), SET_SRC (exp)))
  	  return false;
! 	dest = SET_DEST (exp);
! 	if (dest == pc_rtx)
! 	  return false;
! 	if (!REG_P (dest))
  	  return true;
! 	regno = REGNO (dest);
! 	SET_REGNO_REG_SET (nonequal, regno);
! 	if (regno < FIRST_PSEUDO_REGISTER)
! 	  {
! 	    int n = HARD_REGNO_NREGS (regno, GET_MODE (dest));
! 	    while (--n > 0)
! 	      SET_REGNO_REG_SET (nonequal, regno + n);
! 	  }
  	return false;
  
        default:
*************** thread_jump (mode, e, b)
*** 292,298 ****
       processing as if it were same basic block.
       Our goal is to prove that whole block is an NOOP.  */
  
!   for (insn = NEXT_INSN (b->head); insn != b->end && !failed;
         insn = NEXT_INSN (insn))
    {
      if (INSN_P (insn))
--- 315,321 ----
       processing as if it were same basic block.
       Our goal is to prove that whole block is an NOOP.  */
  
!   for (insn = NEXT_INSN (b->head); insn != NEXT_INSN (b->end) && !failed;
         insn = NEXT_INSN (insn))
    {
      if (INSN_P (insn))

Jump threading fix II

[Jan Hubicka]

Hi,
This finally appears to be the MIPS problem.  When caring the reversed
conditonals I used mistakely first part instead of second. The first in
IF_THEN_ELSE is the condition, not the THEN case.  i386 uses no
reversed conditionals anymore (probably MIPS should not do as well), that
explains why I didn't run into similar problems.

Bootstrapped/regtested i386, MIPS in progress. If it passes I will install
it as obvious.
Sat Jan  5 01:35:54 MET 2002  Jan Hubicka  <jh@suse.cz>
	* cfgcleanup.c (thread_jump): Fix handling of reversed branches.

Index: cfgcleanup.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/cfgcleanup.c,v
retrieving revision 1.29
diff -c -3 -p -r1.29 cfgcleanup.c
*** cfgcleanup.c	2001/12/30 12:20:42	1.29
--- cfgcleanup.c	2002/01/05 00:30:51
*************** thread_jump (mode, e, b)
*** 326,332 ****
    BITMAP_XFREE (nonequal);
    cselib_finish ();
    if ((comparison_dominates_p (code1, code2) != 0)
!       != (XEXP (SET_SRC (set2), 0) == pc_rtx))
      return BRANCH_EDGE (b);
    else
      return FALLTHRU_EDGE (b);
--- 349,355 ----
    BITMAP_XFREE (nonequal);
    cselib_finish ();
    if ((comparison_dominates_p (code1, code2) != 0)
!       != (XEXP (SET_SRC (set2), 1) == pc_rtx))
      return BRANCH_EDGE (b);
    else
      return FALLTHRU_EDGE (b);

Re: Jump threading fix II

[H . J . Lu]

On Sat, Jan 05, 2002 at 01:33:51AM +0100, Jan Hubicka wrote:
> 
> Hi,
> This finally appears to be the MIPS problem.  When caring the reversed
> conditonals I used mistakely first part instead of second. The first in
> IF_THEN_ELSE is the condition, not the THEN case.  i386 uses no
> reversed conditionals anymore (probably MIPS should not do as well), that
> explains why I didn't run into similar problems.
> 
> Bootstrapped/regtested i386, MIPS in progress. If it passes I will install
> it as obvious.

Please make sure you can bootstrap on mips without regressions.


Thanks.


H.J.

Re: Jump threading fix II

[Jan Hubicka]

> On Sat, Jan 05, 2002 at 01:33:51AM +0100, Jan Hubicka wrote:
> > 
> > Hi,
> > This finally appears to be the MIPS problem.  When caring the reversed
> > conditonals I used mistakely first part instead of second. The first in
> > IF_THEN_ELSE is the condition, not the THEN case.  i386 uses no
> > reversed conditionals anymore (probably MIPS should not do as well), that
> > explains why I didn't run into similar problems.
> > 
> > Bootstrapped/regtested i386, MIPS in progress. If it passes I will install
> > it as obvious.
> 
> Please make sure you can bootstrap on mips without regressions.
Unfortunately I can't even do full bootstrap at that box due to disc space
limitations.  The box is owned by university and the maintainer is out of
my reach. I am trying what can I do.

Honza
> 
> 
> Thanks.
> 
> 
> H.J.

Re: Jump threading fix II

[Robert Lipe]

Jan Hubicka wrote:
> Unfortunately I can't even do full bootstrap at that box due to disc space
> limitations.  The box is owned by university and the maintainer is out of
> my reach. I am trying what can I do.

'bootstrap-lean' may help.   It tries to blow up bridges shortly after
it crosses them, but there can still be a bit of a crunch.

RJL

Re: Jump threading fix II

[H . J . Lu]

On Sat, Jan 05, 2002 at 01:33:51AM +0100, Jan Hubicka wrote:
> 
> Hi,
> This finally appears to be the MIPS problem.  When caring the reversed
> conditonals I used mistakely first part instead of second. The first in
> IF_THEN_ELSE is the condition, not the THEN case.  i386 uses no
> reversed conditionals anymore (probably MIPS should not do as well), that
> explains why I didn't run into similar problems.
> 
> Bootstrapped/regtested i386, MIPS in progress. If it passes I will install
> it as obvious.

Here are some codes from your change:

  set1 = pc_set (e->src->end);
  set2 = pc_set (b->end);
  if (((e->flags & EDGE_FALLTHRU) != 0)
      != (XEXP (SET_SRC (set1), 0) == pc_rtx))
    reverse1 = true;

  cond1 = XEXP (SET_SRC (set1), 0);
  cond2 = XEXP (SET_SRC (set2), 0);
  if (reverse1) 
    code1 = reversed_comparison_code (cond1, b->end);
  else
    code1 = GET_CODE (cond1);

  code2 = GET_CODE (cond2);
  reversed_code2 = reversed_comparison_code (cond2, b->end);

  if (!comparison_dominates_p (code1, code2)
      && !comparison_dominates_p (code1, reversed_code2))
    return NULL;

Could you please double check if

  if (((e->flags & EDGE_FALLTHRU) != 0)
      != (XEXP (SET_SRC (set1), 0) == pc_rtx))
    reverse1 = true;

and

  if (reverse1) 
    code1 = reversed_comparison_code (cond1, b->end);
  else
    code1 = GET_CODE (cond1);

are ok? Since your change causes the mips bootstrap failure, may I
suggest you go over

http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html

line by line and convince yourself they are 100% correct?

Thanks.


H.J.

Re: Jump threading fix II

[H . J . Lu]

On Sat, Jan 05, 2002 at 10:47:18AM -0800, H . J . Lu wrote:
> On Sat, Jan 05, 2002 at 01:33:51AM +0100, Jan Hubicka wrote:
> > 
> > Hi,
> > This finally appears to be the MIPS problem.  When caring the reversed
> > conditonals I used mistakely first part instead of second. The first in
> > IF_THEN_ELSE is the condition, not the THEN case.  i386 uses no
> > reversed conditionals anymore (probably MIPS should not do as well), that
> > explains why I didn't run into similar problems.
> > 
> > Bootstrapped/regtested i386, MIPS in progress. If it passes I will install
> > it as obvious.
> 
> Here are some codes from your change:
> 
>   set1 = pc_set (e->src->end);
>   set2 = pc_set (b->end);
>   if (((e->flags & EDGE_FALLTHRU) != 0)
>       != (XEXP (SET_SRC (set1), 0) == pc_rtx))
>     reverse1 = true;
> 
>   cond1 = XEXP (SET_SRC (set1), 0);
>   cond2 = XEXP (SET_SRC (set2), 0);
>   if (reverse1) 
>     code1 = reversed_comparison_code (cond1, b->end);
>   else
>     code1 = GET_CODE (cond1);
> 
>   code2 = GET_CODE (cond2);
>   reversed_code2 = reversed_comparison_code (cond2, b->end);
> 
>   if (!comparison_dominates_p (code1, code2)
>       && !comparison_dominates_p (code1, reversed_code2))
>     return NULL;
> 
> Could you please double check if
> 
>   if (((e->flags & EDGE_FALLTHRU) != 0)
>       != (XEXP (SET_SRC (set1), 0) == pc_rtx))
>     reverse1 = true;
> 
> and
> 
>   if (reverse1) 
>     code1 = reversed_comparison_code (cond1, b->end);
>   else
>     code1 = GET_CODE (cond1);
> 
> are ok? Since your change causes the mips bootstrap failure, may I
> suggest you go over
> 
> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
> 
> line by line and convince yourself they are 100% correct?
> 

Eric, could you please try this patch? It seems quite promising to me. 
But it will take me more than a day to verify it :-). BTW, there are
no regressions on i686.

Thanks.


H.J.
---
2002-01-06  H.J. Lu <hjl@gnu.org>

	* cfgcleanup.c (thread_jump): Fix 2 typos.

--- gcc/cfgcleanup.c.cfg	Sat Jan  5 09:49:28 2002
+++ gcc/cfgcleanup.c	Sat Jan  5 22:15:00 2002
@@ -268,13 +268,13 @@ thread_jump (mode, e, b)
   set1 = pc_set (e->src->end);
   set2 = pc_set (b->end);
   if (((e->flags & EDGE_FALLTHRU) != 0)
-      != (XEXP (SET_SRC (set1), 0) == pc_rtx))
+      != (XEXP (SET_SRC (set1), 1) == pc_rtx))
     reverse1 = true;
 
   cond1 = XEXP (SET_SRC (set1), 0);
   cond2 = XEXP (SET_SRC (set2), 0);
   if (reverse1)
-    code1 = reversed_comparison_code (cond1, b->end);
+    code1 = reversed_comparison_code (cond1, e->src->end);
   else
     code1 = GET_CODE (cond1);
 

Re: Jump threading fix II

[Eric Christopher]

> Eric, could you please try this patch? It seems quite promising to me. 
> But it will take me more than a day to verify it :-). BTW, there are
> no regressions on i686.
>

Ok. It's going now. I'll send an update when it's done.

-eric

-- 
I will not use abbrev.

Re: Jump threading fix II

[H . J . Lu]

On Sun, Jan 06, 2002 at 12:45:18AM -0800, Eric Christopher wrote:
> 
> > Eric, could you please try this patch? It seems quite promising to me. 
> > But it will take me more than a day to verify it :-). BTW, there are
> > no regressions on i686.
> >
> 
> Ok. It's going now. I'll send an update when it's done.
> 

It bootstraped cleanly on Linux/mips. I am running "make check" now.



H.J.

Re: Jump threading fix II

[Jan Hubicka]

> Here are some codes from your change:
> 
>   set1 = pc_set (e->src->end);
>   set2 = pc_set (b->end);
>   if (((e->flags & EDGE_FALLTHRU) != 0)
>       != (XEXP (SET_SRC (set1), 0) == pc_rtx))
>     reverse1 = true;
> 
>   cond1 = XEXP (SET_SRC (set1), 0);
>   cond2 = XEXP (SET_SRC (set2), 0);
>   if (reverse1) 
>     code1 = reversed_comparison_code (cond1, b->end);
>   else
>     code1 = GET_CODE (cond1);
> 
>   code2 = GET_CODE (cond2);
>   reversed_code2 = reversed_comparison_code (cond2, b->end);
> 
>   if (!comparison_dominates_p (code1, code2)
>       && !comparison_dominates_p (code1, reversed_code2))
>     return NULL;
> 
> Could you please double check if
> 
>   if (((e->flags & EDGE_FALLTHRU) != 0)
>       != (XEXP (SET_SRC (set1), 0) == pc_rtx))
>     reverse1 = true;
> 
> and
> 
>   if (reverse1) 
>     code1 = reversed_comparison_code (cond1, b->end);
>   else
>     code1 = GET_CODE (cond1);
> 
> are ok? Since your change causes the mips bootstrap failure, may I
> suggest you go over
This should be OK - the code1 is always reversed in order to be true to
get into the block and code2 is kept in the original form.
WHen choosing the outgoing edges I need to check whether code2 dominates
and choose else or if version of it.

There has been the typo in operand number.  Now I am getting bootstrap
failure, but it is unrelated to threading - even if I disable it it fails.
Other emails seems to suggest that the unrelated problem has been fixed.
> 
> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
> 
> line by line and convince yourself they are 100% correct?

I did that about 3 times - thats why I sent the fixes to hypotetical
bugs (such as hard regnos etc).  The MIPS bug has been the typo/thinko
at very end of thread_jump.

Are you still having problems today?
Hope not :)
Honza
> 
> Thanks.
> 
> 
> H.J.

Re: Jump threading fix II

[H . J . Lu]

On Sun, Jan 06, 2002 at 07:55:22PM +0100, Jan Hubicka wrote:
> This should be OK - the code1 is always reversed in order to be true to
> get into the block and code2 is kept in the original form.
> WHen choosing the outgoing edges I need to check whether code2 dominates
> and choose else or if version of it.
> 
> There has been the typo in operand number.  Now I am getting bootstrap
> failure, but it is unrelated to threading - even if I disable it it fails.
> Other emails seems to suggest that the unrelated problem has been fixed.
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
> > 
> > line by line and convince yourself they are 100% correct?
> 
> I did that about 3 times - thats why I sent the fixes to hypotetical
> bugs (such as hard regnos etc).  The MIPS bug has been the typo/thinko
> at very end of thread_jump.
> 
> Are you still having problems today?
> Hope not :)

I am testing

http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00357.html

It seems very promising. I am running "make check" on Sat Jan  5
09:51:17 PST 2002 with it on Linux/mips now. I also bootstraped Dec 17
09:30 PST 2001 with it and your fixes on mips-sgi-irix6.5.

Please check out why my patch `fixes' the mips problem.


H.J.

Re: Jump threading fix II

[Jan Hubicka]

> On Sun, Jan 06, 2002 at 07:55:22PM +0100, Jan Hubicka wrote:
> > This should be OK - the code1 is always reversed in order to be true to
> > get into the block and code2 is kept in the original form.
> > WHen choosing the outgoing edges I need to check whether code2 dominates
> > and choose else or if version of it.
> > 
> > There has been the typo in operand number.  Now I am getting bootstrap
> > failure, but it is unrelated to threading - even if I disable it it fails.
> > Other emails seems to suggest that the unrelated problem has been fixed.
> > > 
> > > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
> > > 
> > > line by line and convince yourself they are 100% correct?
> > 
> > I did that about 3 times - thats why I sent the fixes to hypotetical
> > bugs (such as hard regnos etc).  The MIPS bug has been the typo/thinko
> > at very end of thread_jump.
> > 
> > Are you still having problems today?
> > Hope not :)
> 
> I am testing
> 
> http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00357.html

> 
> It seems very promising. I am running "make check" on Sat Jan  5
> 09:51:17 PST 2002 with it on Linux/mips now. I also bootstraped Dec 17
> 09:30 PST 2001 with it and your fixes on mips-sgi-irix6.5.
> 

It is really obvious fix.  Thanks for catching that and I apologize for
the problems caused :(
MIPS is one of few "main" targets excercising code in question.  It still looks
like a bug in MIPS md file that the conditionals are not reversable.  I am just
checking MIPS instruction set manual if there is good purpose for this to
happen.

Honza

Re: Jump threading fix II

[H . J . Lu]

On Sun, Jan 06, 2002 at 08:10:05PM +0100, Jan Hubicka wrote:
> > On Sun, Jan 06, 2002 at 07:55:22PM +0100, Jan Hubicka wrote:
> > > This should be OK - the code1 is always reversed in order to be true to
> > > get into the block and code2 is kept in the original form.
> > > WHen choosing the outgoing edges I need to check whether code2 dominates
> > > and choose else or if version of it.
> > > 
> > > There has been the typo in operand number.  Now I am getting bootstrap
> > > failure, but it is unrelated to threading - even if I disable it it fails.
> > > Other emails seems to suggest that the unrelated problem has been fixed.
> > > > 
> > > > http://gcc.gnu.org/ml/gcc-patches/2001-12/msg01658.html
> > > > 
> > > > line by line and convince yourself they are 100% correct?
> > > 
> > > I did that about 3 times - thats why I sent the fixes to hypotetical
> > > bugs (such as hard regnos etc).  The MIPS bug has been the typo/thinko
> > > at very end of thread_jump.
> > > 
> > > Are you still having problems today?
> > > Hope not :)
> > 
> > I am testing
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00357.html
> 
> > 
> > It seems very promising. I am running "make check" on Sat Jan  5
> > 09:51:17 PST 2002 with it on Linux/mips now. I also bootstraped Dec 17
> > 09:30 PST 2001 with it and your fixes on mips-sgi-irix6.5.
> > 
> 
> It is really obvious fix.  Thanks for catching that and I apologize for
> the problems caused :(

I tested it on Linux/mipel:

http://gcc.gnu.org/ml/gcc-testresults/2002-01/msg00096.html

I also bootstraped it on mips-sgi-irix6.5. There are no regressions on
Linux/i686. I am checking it in now.

Thanks.


H.J.

(no subject)

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

At the moment, for a match_dup in a define_cond_exec, you'd have to
give the number in the
resulting pattern(s) rather than in the substitute pattern.  That's
not only wrong, but can also
be impossible when the pattern should apply to multiple patterns with
different operand numbers.

The attached patch fixes this.

Bootstrapped on x86_64-pc-linux-gnu.

[-- Attachment #2: define_cond_exec_patch.txt --]
[-- Type: text/plain, Size: 527 bytes --]

2020-12-12  Joern Rennecke  <joern.rennecke@embecosm.com>

	Fix match_dup bug of define_cond_exec.
	* gensupport.c (alter_predicate_for_insn): Handle MATCH_DUP.

diff --git a/gcc/gensupport.c b/gcc/gensupport.c
index e1ca06dbc1e..92275358078 100644
--- a/gcc/gensupport.c
+++ b/gcc/gensupport.c
@@ -1230,6 +1230,7 @@ alter_predicate_for_insn (rtx pattern, int alt, int max_op,
     case MATCH_OPERATOR:
     case MATCH_SCRATCH:
     case MATCH_PARALLEL:
+    case MATCH_DUP:
       XINT (pattern, 0) += max_op;
       break;
 

Re: none

[Richard Sandiford]

Joern Rennecke <joern.rennecke@embecosm.com> writes:
> At the moment, for a match_dup in a define_cond_exec, you'd have to
> give the number in the
> resulting pattern(s) rather than in the substitute pattern.  That's
> not only wrong, but can also
> be impossible when the pattern should apply to multiple patterns with
> different operand numbers.
>
> The attached patch fixes this.
>
> Bootstrapped on x86_64-pc-linux-gnu.
>
> 2020-12-12  Joern Rennecke  <joern.rennecke@embecosm.com>
>
> 	Fix match_dup bug of define_cond_exec.
> 	* gensupport.c (alter_predicate_for_insn): Handle MATCH_DUP.

The “Fix match_dup …” should come before the changelog in the commit message.

OK otherwise, thanks.

Richard

> diff --git a/gcc/gensupport.c b/gcc/gensupport.c
> index e1ca06dbc1e..92275358078 100644
> --- a/gcc/gensupport.c
> +++ b/gcc/gensupport.c
> @@ -1230,6 +1230,7 @@ alter_predicate_for_insn (rtx pattern, int alt, int max_op,
>      case MATCH_OPERATOR:
>      case MATCH_SCRATCH:
>      case MATCH_PARALLEL:
> +    case MATCH_DUP:
>        XINT (pattern, 0) += max_op;
>        break;
>  

Re: none

[Gabriel Dos Reis]

"Doug Gregor" <doug.gregor@gmail.com> writes:

Am I the only one to receive Doug's recent messages with empty body?

-- Gaby

Re: C++ PATCH: Tree dumper

[Gerald Pfeifer]

On 2 Dec 2001, Alexandre Oliva wrote:
>> (For the web pages also MIME attachments are fine with me.)
> I'd rather go with a uniform set of rules.  Would you *prefer* to get
> patches as MIME attachments, or are the guidelines below ok with you?

I'm pragmatic, so let's go with a uniform set of rules. ;-)

> Ok to install?

Could we have two sentences, as in "This and this and this is fine.
This and this and this is not fine" instead of "This is fine  (while
this is not fine) and this is fine (while this is not fine)"?

I believe it's easier to read and understand what we want that way
-- and the patch is fine with this change.

> ! Avoid MIME large-message splitting (<code>message/partial</code> at
> ! all costs.</p>

I have not seen message/partial in the wild yet, so I think we could
omit this, but if you tell me that you worry about it, I will believe
you. :-)

Thanks,
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: none

[Alexandre Oliva]

On Dec  3, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> On 2 Dec 2001, Alexandre Oliva wrote:
>>> (For the web pages also MIME attachments are fine with me.)
>> I'd rather go with a uniform set of rules.  Would you *prefer* to get
>> patches as MIME attachments, or are the guidelines below ok with you?

> I'm pragmatic, so let's go with a uniform set of rules. ;-)

Thanks

>> Ok to install?

> Could we have two sentences, as in "This and this and this is fine.
> This and this and this is not fine" instead of "This is fine  (while
> this is not fine) and this is fine (while this is not fine)"?

> I believe it's easier to read and understand what we want that way
> -- and the patch is fine with this change.

Thanks, I'm checking this in:

Index: contribute.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.42
diff -u -p -c -r1.42 contribute.html
cvs server: conflicting specifications of output style
*** contribute.html	2001/12/10 10:27:44	1.42
--- contribute.html	2002/01/02 02:40:31
*************** changes easier but do not change GCC's b
*** 120,128 ****
  the changes that actually make use of the new code and change GCC's
  behavior.)</p>
  
! <p>We accept patches as plain text (preferred for the compilers
! themselves), MIME attachments (preferred for the web pages), or as
! uuencoded gzipped text.</p>
  
  <p>When you have all these pieces, bundle them up in a mail message
  and send it to <a
--- 120,137 ----
  the changes that actually make use of the new code and change GCC's
  behavior.)</p>
  
! <p>We prefer patches posted as plain text or as MIME parts of type
! <code>text/x-patch</code> or <code>text/plain</code>, disposition
! <code>inline</code>, encoded as <code>7bit</code> or
! <code>8bit</code>.  If the patch is too big or too mechanical, posting
! it gzipped or bzip2ed and uuencoded or encoded as a
! <code>base64</code> MIME part is acceptable, as long as the ChangeLog
! is still posted as plain text.  Other than that, it is strongly
! discouraged to post patches as MIME parts of type
! <code>application/</code><i>whatever</i>, disposition
! <code>attachment</code> and/or encoded as <code>base64</code> or
! <code>quoted-printable</code>.  Avoid MIME large-message splitting
! (<code>message/partial</code>) at all costs.</p>
  
  <p>When you have all these pieces, bundle them up in a mail message
  and send it to <a


>> ! Avoid MIME large-message splitting (<code>message/partial</code> at
>> ! all costs.</p>

> I have not seen message/partial in the wild yet, so I think we could
> omit this, but if you tell me that you worry about it, I will believe
> you. :-)

I do.  I've seen it before, and it's often annoying to read it even
if your mail reader supports message/partial.  Not to mention the
disruptive effect to the archives.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: none

[Gabriel Dos Reis]

Mark Kettenis <kettenis@wins.uva.nl> writes:

[...]

| I don't have any checkin priviliges.  Besides, my patch did delete the
| Cygwin specific code because I believed that it wasn't necessary
| anymore, but nobody verified this.  And Daniel Berlin was looking at
| BeOS and said he would submit a patch, and I more or less assumed that
| would include the sigsetjmp() stuff too since he said it did solve
| some BeOS-specific problems too.
| 
| Anyway, Alexandres patch looks good to me, and even addresses the
| possibility that sigsetjmp is absent.  So I'm all for it to apply his
| patch instead.

Thanks for the detailed explanation.

Alexandre Oliva <aoliva@redhat.com> writes:

[...]

| Tested on sparc-unknown-linux-gnu, with and without -DHAVE_SIGSETJMP.
| The latter compiled, but would never complete, as before.  Ok to
| install?

Alexandre, can't it be possible to detect HAVE_SIGSETJUMP through
autoconf?  I would prefer an autocoonf-based solution.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: none

[Daniel Berlin]

On 1 Feb 2001, Gabriel Dos Reis wrote:

> Mark Kettenis <kettenis@wins.uva.nl> writes:
>
> [...]
>
> | I don't have any checkin priviliges.  Besides, my patch did delete the
> | Cygwin specific code because I believed that it wasn't necessary
> | anymore, but nobody verified this.  And Daniel Berlin was looking at
> | BeOS and said he would submit a patch, and I more or less assumed that
> | would include the sigsetjmp() stuff too since he said it did solve
> | some BeOS-specific problems too.

I keep meaning to, i'm just busy.
--Dan

Re: none

[Alexandre Oliva]

On Sep  6, 2000, Nick Clifton <nickc@redhat.com> wrote:

>   This patch...

> 2000-09-05  Alexandre Oliva  <aoliva@redhat.com>

> 	* Makefile.in (all-bootstrap): Added all-texinfo and all-zlib.
> 	(bootstrap*): Depend on all-bootstrap.

>   is breaking my bootstraps because the make target 'all-zlib' does
>   not exist.  Did you forget to add this target to the makefile ?

Nope, it wasn't supposed to have been installed before Anthony Green's
patch that zlib in the top-level, but I blindly assumed he had checked
it in everywhere, just like I did :-(

Until his patch propagates to all trees in which I checked my patch
in, I'm checking this one.  Sorry about the breakage, folks.

Re: none

[Alexandre Oliva]

On Sep  6, 2000, Alexandre Oliva <aoliva@redhat.com> wrote:

> Until his patch propagates to all trees in which I checked my patch
> in, I'm checking this one.

I feel dumb!  This is the second time I fail to attach a patch in the
same day! :-(

But this time I have an excuse: cvsdiff had completed, but some
network problem had caused it to produce no output.  Here's the actual
patch: