[patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

The enclosed patch fixes a bootstrap failure on hppa64-hp-hpux11.11
on the 3.5 branch.  The garbage collection done by loop_optimize
poisons recently created RTX nodes.  This patch resolves the problem
by pushing the GGC context after initializing alias analysis.  The
context is popped just before ending alias analysis.  This ensures
that loop_optimize will only cleanup its own garbage.

As the patch that introduced garbage collection in loop_optimize
was back ported to 3.3 and 3.4, I believe this problem can occur
there as well.

The patch has been tested on hppa64-hp-hpux11.11 (3.5),
hppa64-hp-hpux11.00 (3.4), hppa2.0w-hp-hpux11.00 (3.4),
hppa-unknown-linux (3.4, 3.5) with no regressions.

Ok for 3.5, 3.4, 3.3?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

2004-04-16  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	PR bootstrap/14671
	* loop.c (loop_optimize): Push and pop GGC context.

Index: loop.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.497
diff -u -3 -p -r1.497 loop.c
--- loop.c	18 Mar 2004 16:42:31 -0000	1.497
+++ loop.c	16 Apr 2004 00:12:10 -0000
@@ -498,6 +498,7 @@ loop_optimize (rtx f, FILE *dumpfile, in
      We could have added a call to reg_scan after gcse_main in toplev.c,
      but moving this call to init_alias_analysis is more efficient.  */
   init_alias_analysis ();
+  ggc_push_context ();
 
   /* See if we went too far.  Note that get_max_uid already returns
      one more that the maximum uid of all insn.  */
@@ -543,6 +544,7 @@ loop_optimize (rtx f, FILE *dumpfile, in
 	}
     }
 
+  ggc_pop_context ();
   end_alias_analysis ();
 
   /* Clean up.  */

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Mark Mitchell]

John David Anglin wrote:

>The enclosed patch fixes a bootstrap failure on hppa64-hp-hpux11.11
>on the 3.5 branch.  The garbage collection done by loop_optimize
>poisons recently created RTX nodes.  This patch resolves the problem
>by pushing the GGC context after initializing alias analysis.  The
>context is popped just before ending alias analysis.  This ensures
>that loop_optimize will only cleanup its own garbage.
>
>As the patch that introduced garbage collection in loop_optimize
>was back ported to 3.3 and 3.4, I believe this problem can occur
>there as well.
>
>The patch has been tested on hppa64-hp-hpux11.11 (3.5),
>hppa64-hp-hpux11.00 (3.4), hppa2.0w-hp-hpux11.00 (3.4),
>hppa-unknown-linux (3.4, 3.5) with no regressions.
>
>Ok for 3.5, 3.4, 3.3?
>  
>
This patch may very well be correct, but I'd like a little more explanation.

If your patch fixes the problem, then there must be an allocation 
happening somewhere outside of the section of code you bracketed that is 
being collected by the call inside the sectino of code you bracketed.  
What allocation is this?

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> If your patch fixes the problem, then there must be an allocation 
> happening somewhere outside of the section of code you bracketed that is 
> being collected by the call inside the sectino of code you bracketed.  
> What allocation is this?

Yes.  I didn't determine exactly where this occurs but I believe it
happens in init_alias_analysis.  It uses VARRAY_RTX_INIT and VARRAY_GROW.
If I read the code correctly, uses_ggc is 1 for a RTX element.  As a result,
the varray will be allocated using ggc_alloc_cleared.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Mark Mitchell]

John David Anglin wrote:

>>If your patch fixes the problem, then there must be an allocation 
>>happening somewhere outside of the section of code you bracketed that is 
>>being collected by the call inside the sectino of code you bracketed.  
>>What allocation is this?
>>    
>>
>
>Yes.  I didn't determine exactly where this occurs but I believe it
>happens in init_alias_analysis.  It uses VARRAY_RTX_INIT and VARRAY_GROW.
>If I read the code correctly, uses_ggc is 1 for a RTX element.  As a result,
>the varray will be allocated using ggc_alloc_cleared.
>  
>
That sounds highly plausible.  I'd still like to have a more definitive 
understanding.  The reason I'm concerned is that introducing GC contexts 
is expensive, and there might be other similar problems elsewhere.  I'd 
like to have a walk-through of what goes wrong so that we can think 
about it carefully.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> >Yes.  I didn't determine exactly where this occurs but I believe it
> >happens in init_alias_analysis.  It uses VARRAY_RTX_INIT and VARRAY_GROW.
> >If I read the code correctly, uses_ggc is 1 for a RTX element.  As a result,
> >the varray will be allocated using ggc_alloc_cleared.
> >  
> >
> That sounds highly plausible.  I'd still like to have a more definitive 
> understanding.  The reason I'm concerned is that introducing GC contexts 
> is expensive, and there might be other similar problems elsewhere.  I'd 
> like to have a walk-through of what goes wrong so that we can think 
> about it carefully.

Looking back at the PR <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14671>,
I see that it was reg_known_value[294] that was being poisoned.  The
reg_known_value array is created by the following call in init_alias_analysis:

  reg_known_value = ggc_calloc (reg_known_value_size, sizeof (rtx));

So, it's not the VARRAY_RTX_INIT call in this case, although it looks as
if this could also be a problem.

I found by using a watch on reg_known_value[294] that it was being
poisoned by the call to ggc_collect in loop_optimize, around line
542.  Now, the reg_known_value array isn't being poisoned.  It's
only a few of its elements.  I know that they were "recent" elements
because allocations during the running of loop_optimize modified
the in_use word used for the rtx in reg_known_value[294].

I believe that the rtx in question was a MEM accessed via the
frame pointer.

I'd have to do more debugging to determine when and where the rtx
in reg_known_value[294] was created.  I don't understand what stops
the reg_known_value array from being poisoned.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> >Yes.  I didn't determine exactly where this occurs but I believe it
> >happens in init_alias_analysis.  It uses VARRAY_RTX_INIT and VARRAY_GROW.
> >If I read the code correctly, uses_ggc is 1 for a RTX element.  As a result,
> >the varray will be allocated using ggc_alloc_cleared.
> >  
> >
> That sounds highly plausible.  I'd still like to have a more definitive 
> understanding.  The reason I'm concerned is that introducing GC contexts 
> is expensive, and there might be other similar problems elsewhere.  I'd 
> like to have a walk-through of what goes wrong so that we can think 
> about it carefully.

Here's some more information:

This is the rtx that gets poisoned:

(gdb) p debug_rtx (reg_known_value[294])
(plus:DI (reg/f:DI 3 %r3)
    (const_int 272 [0x110]))
(gdb) p reg_known_value[294]
$3 = 0x800003fffe830600

As far as I can tell, rtx's for stack variables are never "registered".
By this, I mean that ggc_mark_roots will not mark the above rtx.  We
have the following code in ggc_collect:

  clear_marks ();
  ggc_mark_roots ();
  poison_pages ();

When loop_optimize calls ggc_collect and the conditions are right
for a collect, clear_marks clears the mark for the object at
reg_known_value[294].  ggc_mark_roots doesn't remark it.  As a
result, the object is poisoned.  A pointer to the poisoned objected
is passed to memrefs_conflict_p (the x rtx is (const_int 0)).

I had thought since the failure occurs in stage 3 that there had
to be a miscompilation in stage 2.  However, the stage 1 compiler
behaves identically except that we don't get the segfault in
memrefs_conflict_p.  In both cases, we have the following rtx
in the y argument:

(gdb) p y
$8 = 0x800003fffe830600
(gdb) p *y
$9 = {code = -23131, mode = 165, jump = 1, call = 0, unchanging = 1,
  volatil = 0, in_struct = 0, used = 1, integrated = 0, frame_related = 1,
  u = {fld = {{rtint = -1515870811, rtuint = 2779096485,
  rtstr = 0xa5a5a5a5a5a5a5a5 <Error reading address 0xa5a5a5a5a5a5a5a5: Bad address>, rtx = 0xa5a5a5a5a5a5a5a5, rtvec = 0xa5a5a5a5a5a5a5a5,
  rttype = 2779096485, rt_addr_diff_vec_flags = {min_align = 165,
  base_after_vec = 1, min_after_vec = 0, max_after_vec = 1,
  min_after_base = 0, max_after_base = 0, offset_unsigned = 1,
  scale = 165}, rt_cselib = 0xa5a5a5a5a5a5a5a5,
  rtbit = 0xa5a5a5a5a5a5a5a5, rttree = 0xa5a5a5a5a5a5a5a5,
  bb = 0xa5a5a5a5a5a5a5a5, rtmem = 0xa5a5a5a5a5a5a5a5,
  rtreg = 0xa5a5a5a5a5a5a5a5}}, hwint = {-6510615555426900571}}}

The define for CONSTANT_P is:

#define CONSTANT_P(X)   \
  (GET_RTX_CLASS (GET_CODE (X)) == RTX_CONST_OBJ                        \
   || GET_CODE (X) == CONST_VECTOR                                      \
   || GET_CODE (X) == CONSTANT_P_RTX)

and

extern const enum rtx_class rtx_class[NUM_RTX_CODE];
#define GET_RTX_CLASS(CODE)             (rtx_class[(int) (CODE)])

The segfault occurs because we have an out-of-range index for the
array rtx_class:

0x40000000000b2374 <memrefs_conflict_p+532>:    ldw,s r20(,r19),r21
(gdb) printf "0x%lx\n",$r19
0x4000000000408c20
(gdb) printf "0x%lx\n",$r20
0xa5a5
(gdb) p *((int *)(0x4000000000408c20 + 4 * 0xa5a5))
Error accessing memory address 0x40000000004322b4: Bad address.

It's just the size of the data section in stage1 that prevents
the segfault.

Ok, so the proposed patch will prevent loop_optimize from poisoning
stuff it shouldn't.  However, there are a whole bunch of calls to
ggc_collect in passes.c.  I suspect that we should push and pop
the context there instead.  If we do that, maybe we don't need the
push and pop in cse.c.  We probably still want the push and pop
in tree-optimize to preserve local variables in the nested case.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Tue, Apr 20, 2004 at 12:04:52PM -0400, John David Anglin wrote:
| > Ok for 3.4?
| 
| Looks ok to me; Mark's still got gate control.

OK for 3.3.4 then.

-- Gaby

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Richard Henderson]

On Tue, Apr 20, 2004 at 12:04:52PM -0400, John David Anglin wrote:
> Ok for 3.4?

Looks ok to me; Mark's still got gate control.


r~

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Mark Mitchell]

John David Anglin wrote:

>>On Apr 19, 2004, at 15:57, John David Anglin wrote:
>>    
>>
>>>The good news is that Richard's patch fixes the problem.  The bad
>>>news is that the patch uses ggc_free which isn't in 3.3 and 3.4.
>>>Implementing ggc_free looks like it would require back porting
>>>3 or 4 more patches.
>>>      
>>>
>>Even better news is that ggc_free is really not need at all, it
>>is an optimization.  You should be able to replace the call to
>>ggc_free with set that variable to NULL and have it work.
>>    
>>
>
>Enclosed is a backport of Richard's patch to 3.4.  The only functional
>difference is the removal of the ggc_free call from end_alias_analysis.
>I believe that this just defers garbage collection of reg_known_value.
>
>I've tested the patch on hppa64-hp-hpux11.00 and hppa-unknown-linux-gnu
>with no regressions.
>
>Ok for 3.4?
>  
>
Yes, this is OK.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> On Apr 19, 2004, at 15:57, John David Anglin wrote:
> >
> > The good news is that Richard's patch fixes the problem.  The bad
> > news is that the patch uses ggc_free which isn't in 3.3 and 3.4.
> > Implementing ggc_free looks like it would require back porting
> > 3 or 4 more patches.
> 
> Even better news is that ggc_free is really not need at all, it
> is an optimization.  You should be able to replace the call to
> ggc_free with set that variable to NULL and have it work.

Enclosed is a backport of Richard's patch to 3.4.  The only functional
difference is the removal of the ggc_free call from end_alias_analysis.
I believe that this just defers garbage collection of reg_known_value.

I've tested the patch on hppa64-hp-hpux11.00 and hppa-unknown-linux-gnu
with no regressions.

Ok for 3.4?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

2004-04-20  Richard Henderson  <rth@redhat.com>

	PR bootstrap/14671
        * alias.c (alias_invariant, alias_invariant_size): Mark GTY.
        (reg_known_value, reg_known_value_size): Likewise; make static.
        (reg_known_equiv_p): Make static.
        (clear_reg_alias_info): Update for new indexing.
        (get_reg_known_value, set_reg_known_value): New.
        (get_reg_known_equiv_p, set_reg_known_equiv_p): New.
        (canon_rtx): Use them. 
        (init_alias_analysis): Likewise.  Allocate reg_known_value with gc.
        Don't play queer offsetting games with reg_known_value and
        reg_known_equiv_p.
        (end_alias_analysis): Don't free reg_known_value.
        * rtl.h (get_reg_known_value, get_reg_known_equiv_p): Declare.
        * sched-deps.c (reg_known_equiv_p, reg_known_value): Remove.
        (deps_may_trap_p, sched_analyze_1, sched_analyze_2): Use the new
        functions instead.

Index: alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.209.2.4
diff -u -3 -p -r1.209.2.4 alias.c
--- alias.c	12 Feb 2004 23:28:27 -0000	1.209.2.4
+++ alias.c	19 Apr 2004 20:13:15 -0000
@@ -181,17 +181,16 @@ static GTY (()) rtx static_reg_base_valu
 
    Because this array contains only pseudo registers it has no effect
    after reload.  */
-static rtx *alias_invariant;
-unsigned int alias_invariant_size;
+static GTY((length("alias_invariant_size"))) rtx *alias_invariant;
+unsigned GTY(()) int alias_invariant_size;
 
 /* Vector indexed by N giving the initial (unchanging) value known for
-   pseudo-register N.  This array is initialized in
-   init_alias_analysis, and does not change until end_alias_analysis
-   is called.  */
-rtx *reg_known_value;
+   pseudo-register N.  This array is initialized in init_alias_analysis,
+   and does not change until end_alias_analysis is called.  */
+static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
 
 /* Indicates number of valid entries in reg_known_value.  */
-static unsigned int reg_known_value_size;
+static GTY(()) unsigned int reg_known_value_size;
 
 /* Vector recording for each reg_known_value whether it is due to a
    REG_EQUIV note.  Future passes (viz., reload) may replace the
@@ -205,7 +204,7 @@ static unsigned int reg_known_value_size
    REG_EQUIV notes.  One could argue that the REG_EQUIV notes are
    wrong, but solving the problem in the scheduler will likely give
    better code, so we do it here.  */
-char *reg_known_equiv_p;
+static bool *reg_known_equiv_p;
 
 /* True when scanning insns from the start of the rtl to the
    NOTE_INSN_FUNCTION_BEG note.  */
@@ -1061,10 +1060,70 @@ clear_reg_alias_info (rtx reg)
 {
   unsigned int regno = REGNO (reg);
 
-  if (regno < reg_known_value_size && regno >= FIRST_PSEUDO_REGISTER)
-    reg_known_value[regno] = reg;
+  if (regno >= FIRST_PSEUDO_REGISTER)
+    {
+      regno -= FIRST_PSEUDO_REGISTER;
+      if (regno < reg_known_value_size)
+	{
+	  reg_known_value[regno] = reg;
+	  reg_known_equiv_p[regno] = false;
+	}
+    }
+}
+
+/* If a value is known for REGNO, return it.  */
+
+rtx 
+get_reg_known_value (unsigned int regno)
+{
+  if (regno >= FIRST_PSEUDO_REGISTER)
+    {
+      regno -= FIRST_PSEUDO_REGISTER;
+      if (regno < reg_known_value_size)
+	return reg_known_value[regno];
+    }
+  return NULL;
 }
 
+/* Set it.  */
+
+static void
+set_reg_known_value (unsigned int regno, rtx val)
+{
+  if (regno >= FIRST_PSEUDO_REGISTER)
+    {
+      regno -= FIRST_PSEUDO_REGISTER;
+      if (regno < reg_known_value_size)
+	reg_known_value[regno] = val;
+    }
+}
+
+/* Similarly for reg_known_equiv_p.  */
+
+bool
+get_reg_known_equiv_p (unsigned int regno)
+{
+  if (regno >= FIRST_PSEUDO_REGISTER)
+    {
+      regno -= FIRST_PSEUDO_REGISTER;
+      if (regno < reg_known_value_size)
+	return reg_known_equiv_p[regno];
+    }
+  return false;
+}
+
+static void
+set_reg_known_equiv_p (unsigned int regno, bool val)
+{
+  if (regno >= FIRST_PSEUDO_REGISTER)
+    {
+      regno -= FIRST_PSEUDO_REGISTER;
+      if (regno < reg_known_value_size)
+	reg_known_equiv_p[regno] = val;
+    }
+}
+
+
 /* Returns a canonical version of X, from the point of view alias
    analysis.  (For example, if X is a MEM whose address is a register,
    and the register has a known value (say a SYMBOL_REF), then a MEM
@@ -1074,11 +1133,16 @@ rtx
 canon_rtx (rtx x)
 {
   /* Recursively look for equivalences.  */
-  if (GET_CODE (x) == REG && REGNO (x) >= FIRST_PSEUDO_REGISTER
-      && REGNO (x) < reg_known_value_size)
-    return reg_known_value[REGNO (x)] == x
-      ? x : canon_rtx (reg_known_value[REGNO (x)]);
-  else if (GET_CODE (x) == PLUS)
+  if (GET_CODE (x) == REG && REGNO (x) >= FIRST_PSEUDO_REGISTER)
+    {
+      rtx t = get_reg_known_value (REGNO (x));
+      if (t == x)
+	return x;
+      if (t)
+	return canon_rtx (t);
+    }
+
+  if (GET_CODE (x) == PLUS)
     {
       rtx x0 = canon_rtx (XEXP (x, 0));
       rtx x1 = canon_rtx (XEXP (x, 1));
@@ -2725,14 +2789,9 @@ init_alias_analysis (void)
 
   timevar_push (TV_ALIAS_ANALYSIS);
 
-  reg_known_value_size = maxreg;
-
-  reg_known_value
-    = (rtx *) xcalloc ((maxreg - FIRST_PSEUDO_REGISTER), sizeof (rtx))
-    - FIRST_PSEUDO_REGISTER;
-  reg_known_equiv_p
-    = (char*) xcalloc ((maxreg - FIRST_PSEUDO_REGISTER), sizeof (char))
-    - FIRST_PSEUDO_REGISTER;
+  reg_known_value_size = maxreg - FIRST_PSEUDO_REGISTER;
+  reg_known_value = ggc_calloc (reg_known_value_size, sizeof (rtx));
+  reg_known_equiv_p = xcalloc (reg_known_value_size, sizeof (bool));
 
   /* Overallocate reg_base_value to allow some growth during loop
      optimization.  Loop unrolling can create a large number of
@@ -2850,6 +2909,7 @@ init_alias_analysis (void)
 		{
 		  unsigned int regno = REGNO (SET_DEST (set));
 		  rtx src = SET_SRC (set);
+		  rtx t;
 
 		  if (REG_NOTES (insn) != 0
 		      && (((note = find_reg_note (insn, REG_EQUAL, 0)) != 0
@@ -2857,29 +2917,28 @@ init_alias_analysis (void)
 			  || (note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) != 0)
 		      && GET_CODE (XEXP (note, 0)) != EXPR_LIST
 		      && ! rtx_varies_p (XEXP (note, 0), 1)
-		      && ! reg_overlap_mentioned_p (SET_DEST (set), XEXP (note, 0)))
+		      && ! reg_overlap_mentioned_p (SET_DEST (set),
+						    XEXP (note, 0)))
 		    {
-		      reg_known_value[regno] = XEXP (note, 0);
-		      reg_known_equiv_p[regno] = REG_NOTE_KIND (note) == REG_EQUIV;
+		      set_reg_known_value (regno, XEXP (note, 0));
+		      set_reg_known_equiv_p (regno,
+			REG_NOTE_KIND (note) == REG_EQUIV);
 		    }
 		  else if (REG_N_SETS (regno) == 1
 			   && GET_CODE (src) == PLUS
 			   && GET_CODE (XEXP (src, 0)) == REG
-			   && REGNO (XEXP (src, 0)) >= FIRST_PSEUDO_REGISTER
-			   && (reg_known_value[REGNO (XEXP (src, 0))])
+			   && (t = get_reg_known_value (REGNO (XEXP (src, 0))))
 			   && GET_CODE (XEXP (src, 1)) == CONST_INT)
 		    {
-		      rtx op0 = XEXP (src, 0);
-		      op0 = reg_known_value[REGNO (op0)];
-		      reg_known_value[regno]
-			= plus_constant (op0, INTVAL (XEXP (src, 1)));
-		      reg_known_equiv_p[regno] = 0;
+		      t = plus_constant (t, INTVAL (XEXP (src, 1)));
+		      set_reg_known_value (regno, t);
+		      set_reg_known_equiv_p (regno, 0);
 		    }
 		  else if (REG_N_SETS (regno) == 1
 			   && ! rtx_varies_p (src, 1))
 		    {
-		      reg_known_value[regno] = src;
-		      reg_known_equiv_p[regno] = 0;
+		      set_reg_known_value (regno, src);
+		      set_reg_known_equiv_p (regno, 0);
 		    }
 		}
 	    }
@@ -2906,9 +2965,9 @@ init_alias_analysis (void)
   while (changed && ++pass < MAX_ALIAS_LOOP_PASSES);
 
   /* Fill in the remaining entries.  */
-  for (i = FIRST_PSEUDO_REGISTER; i < (int)maxreg; i++)
+  for (i = 0; i < (int)reg_known_value_size; i++)
     if (reg_known_value[i] == 0)
-      reg_known_value[i] = regno_reg_rtx[i];
+      reg_known_value[i] = regno_reg_rtx[i + FIRST_PSEUDO_REGISTER];
 
   /* Simplify the reg_base_value array so that no register refers to
      another register, except to special registers indirectly through
@@ -2954,10 +3013,9 @@ void
 end_alias_analysis (void)
 {
   old_reg_base_value = reg_base_value;
-  free (reg_known_value + FIRST_PSEUDO_REGISTER);
   reg_known_value = 0;
   reg_known_value_size = 0;
-  free (reg_known_equiv_p + FIRST_PSEUDO_REGISTER);
+  free (reg_known_equiv_p);
   reg_known_equiv_p = 0;
   if (alias_invariant)
     {
Index: rtl.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/rtl.h,v
retrieving revision 1.448.4.4
diff -u -3 -p -r1.448.4.4 rtl.h
--- rtl.h	25 Mar 2004 16:44:43 -0000	1.448.4.4
+++ rtl.h	19 Apr 2004 20:13:15 -0000
@@ -2303,6 +2303,8 @@ extern void end_alias_analysis (void);
 extern rtx addr_side_effect_eval (rtx, int, int);
 extern bool memory_modified_in_insn_p (rtx, rtx);
 extern rtx find_base_term (rtx);
+extern rtx get_reg_known_value (unsigned int);
+extern bool get_reg_known_equiv_p (unsigned int);
 
 /* In sibcall.c */
 typedef enum {
Index: sched-deps.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/sched-deps.c,v
retrieving revision 1.65.2.1
diff -u -3 -p -r1.65.2.1 sched-deps.c
--- sched-deps.c	23 Jan 2004 23:36:02 -0000	1.65.2.1
+++ sched-deps.c	19 Apr 2004 20:13:15 -0000
@@ -44,8 +44,6 @@ Software Foundation, 59 Temple Place - S
 #include "cselib.h"
 #include "df.h"
 
-extern char *reg_known_equiv_p;
-extern rtx *reg_known_value;
 
 static regset_head reg_pending_sets_head;
 static regset_head reg_pending_clobbers_head;
@@ -113,10 +111,12 @@ deps_may_trap_p (rtx mem)
 {
   rtx addr = XEXP (mem, 0);
 
-  if (REG_P (addr)
-      && REGNO (addr) >= FIRST_PSEUDO_REGISTER
-      && reg_known_value[REGNO (addr)])
-    addr = reg_known_value[REGNO (addr)];
+  if (REG_P (addr) && REGNO (addr) >= FIRST_PSEUDO_REGISTER)
+    {
+      rtx t = get_reg_known_value (REGNO (addr));
+      if (t)
+	addr = t;
+    }
   return rtx_addr_can_trap_p (addr);
 }
 \f
@@ -523,10 +523,12 @@ sched_analyze_1 (struct deps *deps, rtx 
 	  /* Pseudos that are REG_EQUIV to something may be replaced
 	     by that during reloading.  We need only add dependencies for
 	     the address in the REG_EQUIV note.  */
-	  if (!reload_completed
-	      && reg_known_equiv_p[regno]
-	      && GET_CODE (reg_known_value[regno]) == MEM)
-	    sched_analyze_2 (deps, XEXP (reg_known_value[regno], 0), insn);
+	  if (!reload_completed && get_reg_known_equiv_p (regno))
+	    {
+	      rtx t = get_reg_known_value (regno);
+	      if (GET_CODE (t) == MEM)
+	        sched_analyze_2 (deps, XEXP (t, 0), insn);
+	    }
 
 	  /* Don't let it cross a call after scheduling if it doesn't
 	     already cross one.  */
@@ -659,10 +661,12 @@ sched_analyze_2 (struct deps *deps, rtx 
 	    /* Pseudos that are REG_EQUIV to something may be replaced
 	       by that during reloading.  We need only add dependencies for
 	       the address in the REG_EQUIV note.  */
-	    if (!reload_completed
-		&& reg_known_equiv_p[regno]
-		&& GET_CODE (reg_known_value[regno]) == MEM)
-	      sched_analyze_2 (deps, XEXP (reg_known_value[regno], 0), insn);
+	    if (!reload_completed && get_reg_known_equiv_p (regno))
+	      {
+		rtx t = get_reg_known_value (regno);
+		if (GET_CODE (t) == MEM)
+		  sched_analyze_2 (deps, XEXP (t, 0), insn);
+	      }
 
 	    /* If the register does not already cross any calls, then add this
 	       insn to the sched_before_next_call list so that it will still

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Andrew Pinski]

On Apr 19, 2004, at 15:57, John David Anglin wrote:
>
> The good news is that Richard's patch fixes the problem.  The bad
> news is that the patch uses ggc_free which isn't in 3.3 and 3.4.
> Implementing ggc_free looks like it would require back porting
> 3 or 4 more patches.

Even better news is that ggc_free is really not need at all, it
is an optimization.  You should be able to replace the call to
ggc_free with set that variable to NULL and have it work.

-Andrew Pinski

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> > Zdenek Dvorak wrote:
> > 
> > >Almost definitely not; it probably just exposes the problem by changing
> > >the memory consumption and consequently the time when garbage
> > >collections are triggered.
> > 
> > Even if that is so, it is still your responsibility to look into it.
> > 
> > Would you please help J. David to track down what's going on?
> 
> I believe that the problem should be fixed by the inclusion of GTY
> markers on the reg_known_value (which probably should be added to
> whatever other branches contain the fix for PR12440).

The good news is that Richard's patch fixes the problem.  The bad
news is that the patch uses ggc_free which isn't in 3.3 and 3.4.
Implementing ggc_free looks like it would require back porting
3 or 4 more patches.

Richard wrote in
<http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02057.html>:

  No idea why this is happening now, and apparently only to me, but
  the fact is that data gets put into reg_known_value and a call to
  ggc_collect happens before end_alias_analysis.  The call to collect
  happens during CSE, and is protected by a ggc_push_context, but it
  still doesn't seem terribly safe.

Thus, it would seem that the push and pop fix isn't safe.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Zdenek Dvorak]

Hello,

> > > >Almost definitely not; it probably just exposes the problem by changing
> > > >the memory consumption and consequently the time when garbage
> > > >collections are triggered.
> > > 
> > > Even if that is so, it is still your responsibility to look into it.
> > > 
> > > Would you please help J. David to track down what's going on?
> > 
> > I believe that the problem should be fixed by the inclusion of GTY
> > markers on the reg_known_value (which probably should be added to
> > whatever other branches contain the fix for PR12440).
> 
> With the CVS as of D2004.03.26.12.00.00 (i.e., GTY markers on the
> reg_known_value array), GCC bootstraps with --enable-languages=c.
> I'm now doing a full bootstrap.
> 
> I looked at the compilation that was failing with gdb.  However, due
> to changes in memory consumption, garbage collection no longer occurs
> while in loop_optimize.

try setting --param ggc-min-expand=0 --param ggc-min-heapsize=0 (this
should force the garbage collection to occur always).

Zdenek

> I guess that Richard's patch would have
> to be back ported to D2004.03.18.16.43.00 to be absolutely certain
> whether it fixes the problem.
> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> > Zdenek Dvorak wrote:
> > 
> > >Almost definitely not; it probably just exposes the problem by changing
> > >the memory consumption and consequently the time when garbage
> > >collections are triggered.
> > 
> > Even if that is so, it is still your responsibility to look into it.
> > 
> > Would you please help J. David to track down what's going on?
> 
> I believe that the problem should be fixed by the inclusion of GTY
> markers on the reg_known_value (which probably should be added to
> whatever other branches contain the fix for PR12440).

With the CVS as of D2004.03.26.12.00.00 (i.e., GTY markers on the
reg_known_value array), GCC bootstraps with --enable-languages=c.
I'm now doing a full bootstrap.

I looked at the compilation that was failing with gdb.  However, due
to changes in memory consumption, garbage collection no longer occurs
while in loop_optimize.  I guess that Richard's patch would have
to be back ported to D2004.03.18.16.43.00 to be absolutely certain
whether it fixes the problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Zdenek Dvorak]

Hello,

> Zdenek Dvorak wrote:
> 
> >Almost definitely not; it probably just exposes the problem by changing
> >the memory consumption and consequently the time when garbage
> >collections are triggered.
> 
> Even if that is so, it is still your responsibility to look into it.
> 
> Would you please help J. David to track down what's going on?

I believe that the problem should be fixed by the inclusion of GTY
markers on the reg_known_value (which probably should be added to
whatever other branches contain the fix for PR12440).

Zdenek

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Mark Mitchell]

Zdenek Dvorak wrote:

> Almost definitely not; it probably just exposes the problem by changing
> the memory consumption and consequently the time when garbage
> collections are triggered.

Even if that is so, it is still your responsibility to look into it.

Would you please help J. David to track down what's going on?

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> > So, we still have reg/v/f:DI 294 but the rtx is reg_known_value[294]
> > has been orphaned.  ggc_collect poisons the rtx.  Then, the next time
> > scan_loop is called we have a problem with the value for reg 294.
> 
> this does not make sense.  reg_known_value is declared (at least in
> mainline) as
> 
> static GTY((length("reg_known_value_size"))) rtx *reg_known_value;

Yes, it does.  At the time this problem first occurred, the prototype
was

rtx *reg_known_value;

Richard Henderson changed the prototype on March 24.  There have been
several problems appear on the hppa64 port and I was trying to deal
with them sequently.  PR 14829 ocurred just after, then the cgraph
merge by Jan Hubicka on April 2 introduced another problem.

I will check if Richard's change plus my fix for PR 14829
<http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01021.html>
resolves the problem.  If it does, I think Richard's change needs
to be backported to 3.3 and 3.4.

Dave

-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Zdenek Dvorak]

Hello,

> > This suggests that Zdenek's patch on March 18 results in the instructions
> > which use this RTX being removed from the instruction chain but for
> > some reason we are still using reg_known_value[294].  I'll try to look
> > into this.
> 
> This appears to be what's happening.  After gcse, we have:
> 
> (insn 529 527 530 43 ../../gcc/gcc/caller-save.c:713 (set (reg/v/f:DI 294 [ to_save ])
>         (plus:DI (reg/f:DI 3 %r3)
> 	    (const_int 272 [0x110]))) 158 {*pa.md:4807} (nil)
>    (nil))
> 
> Loop changes this to:
> 
> (insn 1435 1434 1437 (set (reg/f:DI 576)
>         (plus:DI (reg/f:DI 3 %r3)
> 	    (const_int 272 [0x110]))) -1 (nil)
>    (nil))
> 
> ...
> 
> (insn 1436 511 1438 (set (reg/f:DI 491)
>         (reg/f:DI 576)) -1 (nil)
>     (nil))
> 
> ...
> 
> (insn 1298 1024 533 (set (reg/v/f:DI 294 [ to_save ])
>         (reg/f:DI 491)) -1 (nil)
>     (nil))
> 
> So, we still have reg/v/f:DI 294 but the rtx is reg_known_value[294]
> has been orphaned.  ggc_collect poisons the rtx.  Then, the next time
> scan_loop is called we have a problem with the value for reg 294.

this does not make sense.  reg_known_value is declared (at least in
mainline) as

static GTY((length("reg_known_value_size"))) rtx *reg_known_value;

so it should keep its members alive by itself (provided that
reg_known_value_size is large enough, which it should be given
the way it is used).

> Maybe my patch is the best solution.  However, I think Zdenek should
> look at this.  The problem may have been introduced with this change:
> 
> 2004-03-18  Zdenek Dvorak  <rakdver@atrey.karlin.mff.cuni.cz>
> 
>         * doloop.c: Removed.
> 	* loop-doloop.c: New file.
> 	* Makefile.in (doloop.o): Remove.
> 	(loop-doloop.o): New.
> 	* cfgloop.h (get_loop_level, doloop_optimize_loops): Declare.
> 	* cfgloopanal.c (get_loop_level): New function.
> 	* loop-iv.c (iv_number_of_iterations): Handle case when loop
> 	is leaved immediatelly.
> 	* loop.c (strength_reduce): Do not call doloop optimization.
> 	* loop.h (LOOP_BCT): Removed.
> 	* passes.c (rest_of_handle_loop_optimize): Do not use LOOP_BCT.
> 	(rest_of_handle_loop2): Call doloop_optimize_loops.
> 	(rest_of_compilation): Test for optimizations moved to
> 	rest_of_handle_loop2.

Almost definitely not; it probably just exposes the problem by changing
the memory consumption and consequently the time when garbage
collections are triggered.

Zdenek

> However, if that's not the case, then the problem applies to 3.3
> and 3.4 as well.
> 
> Dave
> -- 
> J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Mark Mitchell]

John David Anglin wrote:

>>This suggests that Zdenek's patch on March 18 results in the instructions
>>which use this RTX being removed from the instruction chain but for
>>some reason we are still using reg_known_value[294].  I'll try to look
>>into this.
> 
> 
> This appears to be what's happening.  After gcse, we have:

Thanks for continuing to track this down.

> Maybe my patch is the best solution.  However, I think Zdenek should
> look at this.  

Yes, please.  Zdenek?

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> This suggests that Zdenek's patch on March 18 results in the instructions
> which use this RTX being removed from the instruction chain but for
> some reason we are still using reg_known_value[294].  I'll try to look
> into this.

This appears to be what's happening.  After gcse, we have:

(insn 529 527 530 43 ../../gcc/gcc/caller-save.c:713 (set (reg/v/f:DI 294 [ to_save ])
        (plus:DI (reg/f:DI 3 %r3)
	    (const_int 272 [0x110]))) 158 {*pa.md:4807} (nil)
   (nil))

Loop changes this to:

(insn 1435 1434 1437 (set (reg/f:DI 576)
        (plus:DI (reg/f:DI 3 %r3)
	    (const_int 272 [0x110]))) -1 (nil)
   (nil))

...

(insn 1436 511 1438 (set (reg/f:DI 491)
        (reg/f:DI 576)) -1 (nil)
    (nil))

...

(insn 1298 1024 533 (set (reg/v/f:DI 294 [ to_save ])
        (reg/f:DI 491)) -1 (nil)
    (nil))

So, we still have reg/v/f:DI 294 but the rtx is reg_known_value[294]
has been orphaned.  ggc_collect poisons the rtx.  Then, the next time
scan_loop is called we have a problem with the value for reg 294.

Maybe my patch is the best solution.  However, I think Zdenek should
look at this.  The problem may have been introduced with this change:

2004-03-18  Zdenek Dvorak  <rakdver@atrey.karlin.mff.cuni.cz>

        * doloop.c: Removed.
	* loop-doloop.c: New file.
	* Makefile.in (doloop.o): Remove.
	(loop-doloop.o): New.
	* cfgloop.h (get_loop_level, doloop_optimize_loops): Declare.
	* cfgloopanal.c (get_loop_level): New function.
	* loop-iv.c (iv_number_of_iterations): Handle case when loop
	is leaved immediatelly.
	* loop.c (strength_reduce): Do not call doloop optimization.
	* loop.h (LOOP_BCT): Removed.
	* passes.c (rest_of_handle_loop_optimize): Do not use LOOP_BCT.
	(rest_of_handle_loop2): Call doloop_optimize_loops.
	(rest_of_compilation): Test for optimizations moved to
	rest_of_handle_loop2.

However, if that's not the case, then the problem applies to 3.3
and 3.4 as well.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> RTL generated there should be added into the instruction chain, and 
> therefore reachable in other ways.  So, I still think there's not enough 
> information here to know for sure that your patch is correct, and not 
> merely masking some other symptom.

This suggests that Zdenek's patch on March 18 results in the instructions
which use this RTX being removed from the instruction chain but for
some reason we are still using reg_known_value[294].  I'll try to look
into this.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[Mark Mitchell]

John David Anglin wrote:

>>(gdb) p debug_rtx (reg_known_value[294])
>>(plus:DI (reg/f:DI 3 %r3)
>>    (const_int 272 [0x110]))
>>(gdb) p reg_known_value[294]
>>$3 = 0x800003fffe830600
>>    
>>
>
>I probably should add the above rtx is created as follows:
>
>(gdb) bt
>#0  0x4000000000299c10 in rtx_alloc_stat (.)
>    at ../../gcc/gcc/rtl.c:195
>#1  0x4000000000299cb0 in copy_rtx ()
>    at ../../gcc/gcc/rtl.c:250
>#2  0x40000000001a67ac in fixup_var_refs_1 ()
>    at ../../gcc/gcc/function.c:1862
>
RTL generated there should be added into the instruction chain, and 
therefore reachable in other ways.  So, I still think there's not enough 
information here to know for sure that your patch is correct, and not 
merely masking some other symptom.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: [patch 3.3/3.4/3.5] Fix PR bootstrap/14671

[John David Anglin]

> (gdb) p debug_rtx (reg_known_value[294])
> (plus:DI (reg/f:DI 3 %r3)
>     (const_int 272 [0x110]))
> (gdb) p reg_known_value[294]
> $3 = 0x800003fffe830600

I probably should add the above rtx is created as follows:

(gdb) bt
#0  0x4000000000299c10 in rtx_alloc_stat (.)
    at ../../gcc/gcc/rtl.c:195
#1  0x4000000000299cb0 in copy_rtx ()
    at ../../gcc/gcc/rtl.c:250
#2  0x40000000001a67ac in fixup_var_refs_1 ()
    at ../../gcc/gcc/function.c:1862
#3  0x40000000001a664c in fixup_var_refs_1 ()
    at ../../gcc/gcc/function.c:2459
#4  0x40000000001a7614 in fixup_var_refs_insn ()
    at ../../gcc/gcc/function.c:1766
#5  0x40000000001a7c2c in fixup_var_refs ()
    at ../../gcc/gcc/function.c:1649
#6  0x40000000001a7f24 in schedule_fixup_var_refs ()
    at ../../gcc/gcc/function.c:1500
#7  0x40000000001a8118 in put_reg_into_stack ()
    at ../../gcc/gcc/function.c:1474
#8  0x40000000001a8f90 in put_addressof_into_stack ()
    at ../../gcc/gcc/function.c:2939
#9  0x40000000001a97d4 in purge_addressof_1 ()
    at ../../gcc/gcc/function.c:3001
#10 0x40000000001a99d0 in purge_addressof_1 ()
    at ../../gcc/gcc/function.c:3270
#11 0x40000000001a9a44 in purge_addressof_1 ()
    at ../../gcc/gcc/function.c:2990
#12 0x40000000001aa108 in purge_addressof ()
    at ../../gcc/gcc/function.c:3410
#13 0x4000000000303e5c in rest_of_compilation ()
    at ../../gcc/gcc/passes.c:971
    ...

Just thinking that possibly the rtx isn't being correcly associated with
a hash table so that ggc_mark_roots will mark it.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)