Bug 14671 - [3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
Summary: [3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.0.0
: P2 critical
Target Milestone: 3.4.1
Assignee: Not yet assigned to anyone
URL:
Keywords: build, ice-on-valid-code, wrong-code
: 15660 15677 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-03-21 18:28 UTC by John David Anglin
Modified: 2004-10-30 21:10 UTC (History)
7 users (show)

See Also:
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
Known to work: 3.3.3 4.0.0
Known to fail:
Last reconfirmed: 2004-05-27 04:35:48


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2004-03-21 18:28:59 UTC
stage2/xgcc -Bstage2/ -B/opt/gnu64/gcc/gcc-3.5.0-gnu-ld/hppa64-hp-hpux11.11/bin/
 -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-p
rototypes -pedantic -Wno-long-long -Wold-style-definition -Wno-variadic-macros -
Werror -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../gcc/gcc -I../../gcc/gcc/
. -I../../gcc/gcc/../include  ../../gcc/gcc/caller-save.c -o caller-save.o
../../gcc/gcc/caller-save.c: In function `save_call_clobbered_regs':
../../gcc/gcc/caller-save.c:491: internal compiler error: Segmentation fault

Last successful build was at D2004.03.13.00.00.00.
Comment 1 John David Anglin 2004-03-23 03:32:47 UTC
This regression was introduced by the following 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.
Comment 2 John David Anglin 2004-03-23 04:20:52 UTC
The segfault occurs at line 1776 in alias.c:

      if (CONSTANT_P (y))

This generates a misaligned load.  The backtrace is as follows:

#0  memrefs_conflict_p (xsize=Variable "xsize" is not available.
) at ../../gcc/gcc/alias.c:1591
#1  0x40000000000b408c in true_dependence (mem=Variable "mem" is not available.
) at ../../gcc/gcc/alias.c:2142
#2  0x400000000021ccdc in loop_invariant_p (loop=Variable "loop" is not 
available.
)
    at ../../gcc/gcc/loop.c:3378
#3  0x400000000022c1a8 in loop_optimize (f=Variable "f" is not available.
) at ../../gcc/gcc/loop.c:884
#4  0x40000000003032b0 in rest_of_handle_loop_optimize (decl=Variable "decl" is 
not available.
)
    at ../../gcc/gcc/passes.c:1445
#5  0x4000000000305634 in rest_of_compilation (decl=Variable "decl" is not 
available.
)
...

Sorry, gdb isn't working very well on hppa64 at the moment.

Comment 3 John David Anglin 2004-04-04 07:12:40 UTC
The segfault is caused by the poisoning of reg_known_value[294].  It is
initially set to a reasonable rtx in init_alias_analysis.  However, the
garbage collector is now run between optimization of loops
(PR optimization/12440) and this somehow poisons reg_known_value[294].
Comment 4 Andrew Pinski 2004-04-04 07:23:26 UTC
Which does not make senses as reg_known_value is marked as GTY with a length of 
reg_known_value_size, unless this length is wrong at the point gc_collect is called which means this is 
most likely caused by a patch by Jan.
Comment 5 dave 2004-04-04 07:54:51 UTC
Subject: Re:  [3.5 regression] caller-save.c:491: interna

> Which does not make senses as reg_known_value is marked as GTY with a length
> of 
> reg_known_value_size, unless this length is wrong at the point gc_collect is
> called which means this is 
> most likely caused by a patch by Jan.

No.  On March 18, xcalloc was being used to allocate reg_known_value
and it wasn't marked.  RTH seems to have applied a patch to mark
reg_known_value on the 24th.  So, possibly this PR is fixed.

Dave
Comment 6 dave 2004-04-04 08:08:48 UTC
Subject: Re:  [3.5 regression] caller-save.c:491: interna

> No.  On March 18, xcalloc was being used to allocate reg_known_value
> and it wasn't marked.  RTH seems to have applied a patch to mark
> reg_known_value on the 24th.  So, possibly this PR is fixed.

This patch

2004-01-20  Zdenek Dvorak  <rakdver@atrey.karlin.mff.cuni.cz>

        PR optimization/12440
	* loop.c: Include ggc.h.
	(loop_optimize): Run garbage collector between optimization of loops.
	* Makefile.in (loop.o): Add GGC_H dependency.

was also applied to the 3.3 and 3.4 branches but reg_known_value isn't
marked.

Dave
Comment 7 dave 2004-04-04 16:42:22 UTC
Subject: Re:  [3.5 regression] caller-save.c:491: interna

> Which does not make senses as reg_known_value is marked as GTY with a length
> of 
> reg_known_value_size, unless this length is wrong at the point gc_collect is
> called which means this is 
> most likely caused by a patch by Jan.

I realized that my previous comments have caused confusion.  The
reg_known_value object isn't getting garbage collected.  It's the
object pointed to by reg_known_value[294] that's being poisoned.

What I did was put a watch on "reg_known_value[294]->code != PLUS"
after the array location had been initialized in init_alias_analysis.
From previous analysis, I had determined that this rtx was being
returned by the call to canon_rtx (x_addr) in true_dependence.
When the watch triggered, a backtrace showed that garbage collection
was triggered by the call to ggc_collect in loop_optimize.

Do we need to copy `src' in the following assignment?

                  else if (REG_N_SETS (regno) == 1
			   && ! rtx_varies_p (src, 1))
		    {
		      reg_known_value[regno] = src;

I'm beginning to suspect that bootstrap/14829 is just a different
symptom of the same problem.

Dave
Comment 8 Mark Mitchell 2004-04-04 23:05:16 UTC
Dave, can you confirm whether or not this PR is fixed?
Comment 9 dave 2004-04-04 23:31:39 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> ------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-04-04
> 23:05 -------
> Dave, can you confirm whether or not this PR is fixed?

This PR is not fixed and not fully understood.  At the moment, the
effect on 3.3/3.4 is hypothetical.  Clearly, the in_use bit for
the object is not set or has been clobbered.  The stage1 compiler
doesn't have the same problem.

The enclosed patch appears to "fix" the problem but it doesn't
explain why things broke with Zdenek's patch of March 18.

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

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	4 Apr 2004 23:21:30 -0000
@@ -537,10 +537,7 @@ loop_optimize (rtx f, FILE *dumpfile, in
       struct loop *loop = &loops->array[i];
 
       if (! loop->invalid && loop->end)
-	{
-	  scan_loop (loop, flags);
-	  ggc_collect ();
-	}
+	scan_loop (loop, flags);
     }
 
   end_alias_analysis ();
Comment 10 dave 2004-04-07 04:24:15 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> ------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-04-04
> 23:05 -------
> Dave, can you confirm whether or not this PR is fixed?

I studied this problem further today.  The in_use flag for the node
that causes the segfault is being cleared by clear_marks.  clear_marks
is called from ggc_collect.  ggc_collect is called from loop_optimize.

It would appear that there are a few ggc objects created after the last
context push (possibly in init_alias_once).  These get garbage collected
and cause the segfault.

I believe that the enclosed patch will fix the problem.  The problem
affects 3.3 onward.

The patch is not fully tested.  I'm still struggling with bootstrap/14829.
CVS access for me has been terrible the last couple of days.

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

2004-04-07  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	6 Apr 2004 23:27:05 -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.  */
Comment 11 CVS Commits 2004-04-21 19:52:41 UTC
Subject: Bug 14671

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	danglin@gcc.gnu.org	2004-04-21 19:52:38

Modified files:
	gcc            : ChangeLog alias.c rtl.h sched-deps.c 

Log message:
	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.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.404&r2=2.2326.2.405
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/alias.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.209.2.4&r2=1.209.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtl.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.448.4.4&r2=1.448.4.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/sched-deps.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.65.2.1&r2=1.65.2.2

Comment 12 John David Anglin 2004-04-21 19:59:51 UTC
Fixed by <http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02057.html>
on trunk.
Comment 13 CVS Commits 2004-04-24 19:40:52 UTC
Subject: Bug 14671

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	danglin@gcc.gnu.org	2004-04-24 19:40:46

Modified files:
	gcc            : ChangeLog alias.c rtl.h sched-deps.c 

Log message:
	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.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.969&r2=1.16114.2.970
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/alias.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.181.2.3&r2=1.181.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtl.h.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.375.2.7&r2=1.375.2.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/sched-deps.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.49.2.1&r2=1.49.2.2

Comment 14 Eric Botcazou 2004-05-25 10:14:17 UTC
The backport to the 3.3 branch causes regressions in the POOMA testsuite on x86.
Comment 15 dave 2004-05-25 14:46:52 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> The backport to the 3.3 branch causes regressions in the POOMA testsuite on
> x86.

Do you have more details?  I could understand that the patch might
cause a compilation performance regression as it prevents the garbage
collection of some objects that were previously being collected.

I don't have a functional x86 machine at the moment, so I can't help
much in researching this problem.

Dave
Comment 16 Andrew Pinski 2004-05-26 12:31:24 UTC
*** Bug 15660 has been marked as a duplicate of this bug. ***
Comment 17 Richard Biener 2004-05-26 12:41:21 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

Dave, you asked for details on the POOMA regressions.  They are ICEs of
the compiler of sort of described in PR15660.  Reverting the patch fixes
the ICEs.

Richard.
Comment 18 Eric Botcazou 2004-05-26 14:26:28 UTC
Sorry, Dave, I forgot to add myself to the CC list so I missed you message.

As Richard said, the patch introduced GC-related ICEs in the POOMA testsuite on
the 3.3 branch.  Is this patch really required on that branch?

[My personal feeling is that touching the GC should not be allowed on a release
branch and that we started to pull the string with Zdenek's patch.]
Comment 19 dave 2004-05-26 17:53:02 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> ------- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
> dot de  2004-05-26 12:41 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
>  internal compiler error: Segmentation fault
> 
> Dave, you asked for details on the POOMA regressions.  They are ICEs of
> the compiler of sort of described in PR15660.  Reverting the patch fixes
> the ICEs.

Looking at PR15660, the connection to the patch seems tenuous (
#2  0x080dcc14 in gt_ggc_ma_alias_invariant).  PR14671 fixed a problem
where objects in reg_known_value were being poissoned because objects
in reg_known_value weren't being marked.  This was triggered by the
addition of the ggc_collect () call in loop.c to fix a different PR.
We have a similar situation here.

More debugging needs to be done to find more about "p" and what's
really the problem in marking this object.

In my opinion, PR14671 can't be reverted unless PR12440 is reverted
(i.e., the garbage collection in loop_optimize).  Otherwise, we are
just trading one failure for another.

Dave
Comment 20 Eric Botcazou 2004-05-26 18:02:22 UTC
I think Zdenek's patch should be reverted and all the follow-up patches too. 
The problem it aimed to fix is not a code generation problem, only a memory
explosion on a pathological code.  As demonstrated by this PR and Richard's
problems with POOMA, tweaking the GC is simply like opening a can of worms and
we have neither the time nor the resources to deal with that on the 3.3 branch.
Comment 21 Gabriel Dos Reis 2004-05-26 18:31:55 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault

"ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| I think Zdenek's patch should be reverted and all the follow-up patches too. 
| The problem it aimed to fix is not a code generation problem, only a memory
| explosion on a pathological code.  As demonstrated by this PR and Richard's
| problems with POOMA, tweaking the GC is simply like opening a can of worms and
| we have neither the time nor the resources to deal with that on the 3.3 branch.

I appreciate all your hard works and time on this issue.
I queue your proposed patch for 3.3.5.  It won't make it into 3.3.4, 
unfortunately. The alpha-dec problem will the last one to be solved
for 3.3.4.

Richard's problem with POOMA is a _long_ standaing problem starting
with 3.3.0.  It is not triggered by a recent patch. It just happens
that many bugs are intertweaned. I really want to help solve this
problem, but I don't think we should revert Dave's or Zdenek's patch.
I want to help all interested parties to get forward.

-- Gaby

 
Comment 22 Eric Botcazou 2004-05-26 18:49:12 UTC
No, Richard discovered other regressions in the POOMA testsuite that were
introduced by Dave backporting rth's patch on 04/24.  Therefore they will be
regressions in GCC 3.3.4 with regard to GCC 3.3.3 if the former is released in
the current state (my patch is totally unrelated here).  I think they deserve
some consideration because they are _serious_ IMHO.
Comment 23 Gabriel Dos Reis 2004-05-26 19:24:35 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault

"ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| No, Richard discovered other regressions in the POOMA testsuite that were

My understanding has been that, your proposed patch would trigger those
regressions.  Apparently, thta would not be the case.  Which means, I
would need a summary from someone like you or Richard, but as balanced
as possible :-).

| introduced by Dave backporting rth's patch on 04/24.  Therefore they will be
| regressions in GCC 3.3.4 with regard to GCC 3.3.3 if the former is released in
| the current state (my patch is totally unrelated here).  I think they deserve
| some consideration because they are _serious_ IMHO.

I'm not saying I don't consider them.  For the record, I consider
regressions, by default, as serious 

-- Gaby
Comment 24 Eric Botcazou 2004-05-26 19:40:27 UTC
> My understanding has been that, your proposed patch would trigger those
> regressions.  Apparently, thta would not be the case.  Which means, I
> would need a summary from someone like you or Richard, but as balanced
> as possible :-).

Ok, then there was kind of a misunderstanding on both sides.  The regressions
were filed as PR middle-end/15660 by Richard.
Comment 25 Richard Biener 2004-05-26 20:36:11 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

gdr at integrable-solutions dot net wrote:
> ------- Additional Comments From gdr at integrable-solutions dot net  2004-05-26 19:24 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
> 
> "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
> 
> | No, Richard discovered other regressions in the POOMA testsuite that were
> 
> My understanding has been that, your proposed patch would trigger those
> regressions.  Apparently, thta would not be the case.  Which means, I
> would need a summary from someone like you or Richard, but as balanced
> as possible :-).

The original long standing POOMA regressions were fixed by Eric.  Many 
thanks to that!

The new regression caused by Dave backporting rth's patch on 04/24 is 
unrelated and was detected by me only because I did a full regression 
run on the POOMA tests with the (appearantly) fixed compiler.  These 
regressions are against 3.3.3, and I suspect not only POOMA will trigger 
this (its actually five tests that are failing due to gcc ICEing).  As 
the failure can easily be fixed by reverting patches that do not fix 
regressions to older releases I seriously propose doing so.

But it's your call Gaby, and I personally won't be unhappy, because I 
fully switched to using 3.4 already and even have reverted rth's patch 
in my local tree.  But I suspect that not everybody is building gccs on 
a daily basis like me :)

> | introduced by Dave backporting rth's patch on 04/24.  Therefore they will be
> | regressions in GCC 3.3.4 with regard to GCC 3.3.3 if the former is released in
> | the current state (my patch is totally unrelated here).  I think they deserve
> | some consideration because they are _serious_ IMHO.
> 
> I'm not saying I don't consider them.  For the record, I consider
> regressions, by default, as serious 

So this would be serious then.

Richard.
Comment 26 dave 2004-05-27 03:38:06 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> The new regression caused by Dave backporting rth's patch on 04/24 is 
> unrelated and was detected by me only because I did a full regression 
> run on the POOMA tests with the (appearantly) fixed compiler.

This assertion has not been proved.  I've seen a number of bugs recently
that were totally unrelated to the change that introduced them.

If you look at the comment in ggc-page.c for lookup_page_table_entry,
you will see that it says "Die (probably) if the object wasn't allocated
via GC."  The patch in question didn't create the object that caused
the ICE.  Thus, as I indicated previously, more information is needed
about the object that caused the ICE, and how and when it was added
to the alias_invariant array.

The alias_invariant array is supposed to contain RTX objects and these
are always allocated via GC as far as I know.  So, marking the objects
in this array shouldn't be a problem unless some are not GC objects.

Richard has indicated that the regression isn't present on 3.4, yet it
has essentially the same change.  If we revert this on 3.5, the pa and
alpha won't build.  The build problems are critical for these ports.

Dave
Comment 27 Andrew Pinski 2004-05-27 03:50:50 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault


On May 26, 2004, at 23:38, dave at hiauly1 dot hia dot nrc dot ca wrote:

> If you look at the comment in ggc-page.c for lookup_page_table_entry,
> you will see that it says "Die (probably) if the object wasn't 
> allocated
> via GC."  The patch in question didn't create the object that caused
> the ICE.  Thus, as I indicated previously, more information is needed
> about the object that caused the ICE, and how and when it was added
> to the alias_invariant array.

> Richard has indicated that the regression isn't present on 3.4, yet it
> has essentially the same change.  If we revert this on 3.5, the pa and
> alpha won't build.  The build problems are critical for these ports.


I think this was fixed lately on the mainline fully by:
<http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01413.html>.

Could someone test the backport of this patch, ggc_free can be safely
removed as it is an optimization

Thanks,
Andrew Pinski

Comment 28 Gabriel Dos Reis 2004-05-27 03:55:57 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault

"pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
| 
| 
| On May 26, 2004, at 23:38, dave at hiauly1 dot hia dot nrc dot ca wrote:
| 
| > If you look at the comment in ggc-page.c for lookup_page_table_entry,
| > you will see that it says "Die (probably) if the object wasn't 
| > allocated
| > via GC."  The patch in question didn't create the object that caused
| > the ICE.  Thus, as I indicated previously, more information is needed
| > about the object that caused the ICE, and how and when it was added
| > to the alias_invariant array.
| 
| > Richard has indicated that the regression isn't present on 3.4, yet it
| > has essentially the same change.  If we revert this on 3.5, the pa and
| > alpha won't build.  The build problems are critical for these ports.
| 
| 
| I think this was fixed lately on the mainline fully by:
| <http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01413.html>.

Andrew --

Thanks for the detective work.

| Could someone test the backport of this patch, ggc_free can be safely
| removed as it is an optimization

Richard --
Can you try that?  If it works, I'll apply it immediately, plus
Eric's patch.  Whic I suppose would resolve this very interesting
issue. 

(And any Alpha expert around is also needed :-))

-- Gaby
Comment 29 Andrew Pinski 2004-05-27 04:35:47 UTC
Just confirming this.
Comment 30 Richard Biener 2004-05-27 07:54:03 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

On Thu, 27 May 2004, dave at hiauly1 dot hia dot nrc dot ca wrote:

>
> ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-05-27 03:38 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int
>
> > The new regression caused by Dave backporting rth's patch on 04/24 is
> > unrelated and was detected by me only because I did a full regression
> > run on the POOMA tests with the (appearantly) fixed compiler.
>
> This assertion has not been proved.  I've seen a number of bugs recently
> that were totally unrelated to the change that introduced them.

Well, it has, in so far as reverting the patch fixes the problem.  Of
course the patch may just uncover a latent problem - but that still makes
rth (or the backporter) responsible of fixing the fallout.
Comment 31 Richard Biener 2004-05-27 08:02:24 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

On Thu, 27 May 2004, gdr at integrable-solutions dot net wrote:

>
> ------- Additional Comments From gdr at integrable-solutions dot net  2004-05-27 03:55 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
>
> "pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> writes:
>
> | Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
> |
> |
> | On May 26, 2004, at 23:38, dave at hiauly1 dot hia dot nrc dot ca wrote:
> |
> | > If you look at the comment in ggc-page.c for lookup_page_table_entry,
> | > you will see that it says "Die (probably) if the object wasn't
> | > allocated
> | > via GC."  The patch in question didn't create the object that caused
> | > the ICE.  Thus, as I indicated previously, more information is needed
> | > about the object that caused the ICE, and how and when it was added
> | > to the alias_invariant array.
> |
> | > Richard has indicated that the regression isn't present on 3.4, yet it
> | > has essentially the same change.  If we revert this on 3.5, the pa and
> | > alpha won't build.  The build problems are critical for these ports.
> |
> |
> | I think this was fixed lately on the mainline fully by:
> | <http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01413.html>.
>
> Andrew --
>
> Thanks for the detective work.
>
> | Could someone test the backport of this patch, ggc_free can be safely
> | removed as it is an optimization
>
> Richard --
> Can you try that?  If it works, I'll apply it immediately, plus
> Eric's patch.  Whic I suppose would resolve this very interesting
> issue.

Ok, I just started bootstrapping a compiler with rth's patch re-applied,
the fix for PR14671 and the fix from
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01413.html applied with the
ggc_free hunk modified as:

@@ -2985,7 +2983,6 @@
   reg_base_value_size = 0;
   if (alias_invariant)
     {
-      free (alias_invariant);
       alias_invariant = 0;
       alias_invariant_size = 0;
     }

Comment 32 Richard Biener 2004-05-27 09:38:06 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

On Thu, 27 May 2004, gdr at integrable-solutions dot net wrote:

>
> ------- Additional Comments From gdr at integrable-solutions dot net  2004-05-27 03:55 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
>
> "pinskia at physics dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> writes:
>
> | Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
> |
> |
> | On May 26, 2004, at 23:38, dave at hiauly1 dot hia dot nrc dot ca wrote:
> |
> | > If you look at the comment in ggc-page.c for lookup_page_table_entry,
> | > you will see that it says "Die (probably) if the object wasn't
> | > allocated
> | > via GC."  The patch in question didn't create the object that caused
> | > the ICE.  Thus, as I indicated previously, more information is needed
> | > about the object that caused the ICE, and how and when it was added
> | > to the alias_invariant array.
> |
> | > Richard has indicated that the regression isn't present on 3.4, yet it
> | > has essentially the same change.  If we revert this on 3.5, the pa and
> | > alpha won't build.  The build problems are critical for these ports.
> |
> |
> | I think this was fixed lately on the mainline fully by:
> | <http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01413.html>.
>
> Andrew --
>
> Thanks for the detective work.
>
> | Could someone test the backport of this patch, ggc_free can be safely
> | removed as it is an optimization
>
> Richard --
> Can you try that?  If it works, I'll apply it immediately, plus
> Eric's patch.  Whic I suppose would resolve this very interesting
> issue.

It doesn't solve the problem.  Now it ICEs even compiling the library
itself:

rguenth@alwazn r2 $ g++-3.3 -c
/net/bellatrix/home/rguenth/src/pooma-bk/r2/src/IO/DiskLayout.cmpl.cpp -o
/net/bellatrix/home/rguenth/src/pooma-bk/r2/src/IO/LINUXgcc33a/DiskLayout.cmpl.o
-ftemplate-depth-60 -fno-exceptions -Drestrict=__restrict__   -O2
-funroll-loops -g -I/net/bellatrix/home/rguenth/src/pooma-bk/r2/src
-I/net/bellatrix/home/rguenth/src/pooma-bk/r2/lib/LINUXgcc33a -v
Reading specs from
/net/bellatrix/home/rguenth/ix86/gcc3.3-270504/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with: /home/rguenth/src/gcc/gcc3.3/configure
--prefix=/home/rguenth/ix86/gcc3.3-270504 --enable-languages=c,c++,f77
--enable-threads=posix --enable-__cxa_atexit
--disable-libunwind-exceptions --disable-checking
Thread model: posix
gcc version 3.3.4 20040527 (prerelease)

/net/bellatrix/home/rguenth/ix86/gcc3.3-270504/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.4/cc1plus
-quiet -v -I/net/bellatrix/home/rguenth/src/pooma-bk/r2/src
-I/net/bellatrix/home/rguenth/src/pooma-bk/r2/lib/LINUXgcc33a -iprefix
/net/bellatrix/home/rguenth/ix86/gcc3.3-270504/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.3.4/
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -D_GNU_SOURCE
-Drestrict=__restrict__
/net/bellatrix/home/rguenth/src/pooma-bk/r2/src/IO/DiskLayout.cmpl.cpp
-D__GNUG__=3 -quiet -dumpbase DiskLayout.cmpl.cpp -auxbase-strip
/net/bellatrix/home/rguenth/src/pooma-bk/r2/src/IO/LINUXgcc33a/DiskLayout.cmpl.o
-g -O2 -version -ftemplate-depth-60 -fno-exceptions -funroll-loops -o
/tmp/cc4cbxod.s
GNU C++ version 3.3.4 20040527 (prerelease) (i686-pc-linux-gnu)
	compiled by GNU C version 3.3.4 20040527 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
...
/net/bellatrix/home/rguenth/ix86/gcc3.3-270504/include/c++/3.3.4/bits/vector.tcc:
In
   member function `void std::vector<_Tp,
   _Alloc>::_M_insert_aux(__gnu_cxx::__normal_iterator<_Tp*,
std::vector<_Tp,
   _Alloc> >, const _Tp&) [with _Tp = Observer<UniformGridLayoutData<3>
>*,
   _Alloc = std::allocator<Observer<UniformGridLayoutData<3> >*>]':
/net/bellatrix/home/rguenth/ix86/gcc3.3-270504/include/c++/3.3.4/bits/stl_vector.h:603:
instantiated from `void std::vector<_Tp, _Alloc>::push_back(const _Tp&)
[with _Tp = Observer<UniformGridLayoutData<3> >*, _Alloc =
std::allocator<Observer<UniformGridLayoutData<3> >*>]'
/net/bellatrix/home/rguenth/src/pooma-bk/r2/src/IO/DiskLayout.cmpl.cpp:172:
instantiated from `bool DiskLayout<Dim>::checkLayout() [with int Dim = 3]'
/net/bellatrix/home/rguenth/src/pooma-bk/r2/src/IO/DiskLayout.cmpl.cpp:391:
instantiated from here
/net/bellatrix/home/rguenth/ix86/gcc3.3-270504/include/c++/3.3.4/bits/vector.tcc:257:
internal compiler error: Segmentation
   fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

within gdb its now (look at the invalid pointers passed as args
everywhere):

Program received signal SIGSEGV, Segmentation fault.
0x080dabd1 in memrefs_conflict_p (xsize=4, x=0x26e, ysize=4, y=0x4d5ce960,
c=4)
    at /home/rguenth/src/gcc/gcc3.3/gcc/alias.c:1634
1634	{
(gdb) bt
#0  0x080dabd1 in memrefs_conflict_p (xsize=4, x=0x26e, ysize=4,
y=0x4d5ce960,
    c=4) at /home/rguenth/src/gcc/gcc3.3/gcc/alias.c:1634
#1  0x080db011 in memrefs_conflict_p (xsize=4, x=0x4d84aad4, ysize=4,
    y=0x4d5ce960, c=4) at /home/rguenth/src/gcc/gcc3.3/gcc/alias.c:1755
#2  0x080dbf17 in write_dependence_p (mem=0x4d84ac00, x=0x4d5ceb4c,
writep=0)
    at /home/rguenth/src/gcc/gcc3.3/gcc/alias.c:2344
#3  0x080dbfd0 in anti_dependence (mem=0x4, x=0x4)
    at /home/rguenth/src/gcc/gcc3.3/gcc/alias.c:2363
#4  0x080fbd7c in cselib_mem_conflict_p (mem_base=0x4d5ceb4c,
val=0x4d84ac00)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1053
#5  0x080fbe7c in cselib_invalidate_mem_1 (slot=0x4, info=0x4d5ceb4c)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1133
#6  0x082ff2bf in htab_traverse (htab=0x49233ec8,
    callback=0x80fbe10 <cselib_invalidate_mem_1>, info=0x4d5ceb4c)
    at /home/rguenth/src/gcc/gcc3.3/libiberty/hashtab.c:548
#7  0x080fbee2 in cselib_invalidate_mem (mem_rtx=0x4)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1143
#8  0x080fbf4b in cselib_invalidate_rtx (dest=0x4d5ceb4c,
ignore=0x4d5ceb7c,
    data=0x0) at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1163
#9  0x0824a179 in note_stores (x=0x4d5ceb7c,
    fun=0x80fbef0 <cselib_invalidate_rtx>, data=0x0)
    at /home/rguenth/src/gcc/gcc3.3/gcc/rtlanal.c:1639
#10 0x080fc1d9 in cselib_record_sets (insn=0x4)
---Type <return> to continue, or q <return> to quit---
    at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1296
#11 0x080fc406 in cselib_process_insn (insn=0x48c46108)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1353
#12 0x0815c414 in local_cprop_pass (alter_jumps=1)
    at /home/rguenth/src/gcc/gcc3.3/gcc/gcse.c:4488
#13 0x0815c689 in one_cprop_pass (pass=4, alter_jumps=1)
    at /home/rguenth/src/gcc/gcc3.3/gcc/gcse.c:4562
#14 0x081578d7 in gcse_main (f=0x48c1ddc0, file=0x0)
    at /home/rguenth/src/gcc/gcc3.3/gcc/gcse.c:895
#15 0x08263cdd in rest_of_compilation (decl=0x4a637620)
    at /home/rguenth/src/gcc/gcc3.3/gcc/toplev.c:2874
#16 0x080b908e in genrtl_finish_function (fn=0x4a637620)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cp/semantics.c:2589
#17 0x080b8dbd in expand_body (fn=0x4a637620)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cp/semantics.c:2412
#18 0x08077688 in instantiate_decl (d=0x0, defer_ok=0)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cp/pt.c:10578
#19 0x080779d0 in instantiate_pending_templates ()
    at /home/rguenth/src/gcc/gcc3.3/gcc/cp/pt.c:10655
#20 0x08087abf in finish_file ()
    at /home/rguenth/src/gcc/gcc3.3/gcc/cp/decl2.c:2807
#21 0x08091dac in yyparse () at parse.y:489
#22 0x080d36e9 in c_common_parse_file (set_yydebug=4)
---Type <return> to continue, or q <return> to quit---
    at /home/rguenth/src/gcc/gcc3.3/gcc/c-lex.c:159
#23 0x08261f5a in compile_file ()
    at /home/rguenth/src/gcc/gcc3.3/gcc/toplev.c:2130
#24 0x082670e7 in do_compile ()
    at /home/rguenth/src/gcc/gcc3.3/gcc/toplev.c:5414
#25 0x0826717b in toplev_main (argc=4, argv=0x0)
    at /home/rguenth/src/gcc/gcc3.3/gcc/toplev.c:5444
#26 0x080d93cb in main (argc=4, argv=0x4)
    at /home/rguenth/src/gcc/gcc3.3/gcc/main.c:35
#27 0x4003a8ae in __libc_start_main () from /lib/libc.so.6
(gdb) up 11
#11 0x080fc406 in cselib_process_insn (insn=0x48c46108)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1353
1353	  cselib_record_sets (insn);
(gdb) call debug_rtx(insn)
(insn 50 49 56 2 0x48cca02c (set (mem:SI (reg:SI 63) [664 S4 A32])
        (reg:SI 72)) 38 {*movsi_1} (nil)
    (nil))
(gdb) down 1
#10 0x080fc1d9 in cselib_record_sets (insn=0x4)
    at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1296
1296	  note_stores (body, cselib_invalidate_rtx, NULL);
(gdb) print insn
$2 = 0x4
(gdb) call debug_rtx(body)
(set (mem:SI (reg:SI 63) [664 S4 A32])
    (reg:SI 72))
(gdb) down 2
#8  0x080fbf4b in cselib_invalidate_rtx (dest=0x4d5ceb4c,
ignore=0x4d5ceb7c,
    data=0x0) at /home/rguenth/src/gcc/gcc3.3/gcc/cselib.c:1163
1163	    cselib_invalidate_mem (dest);
(gdb) call debug_rtx(dest)
(mem:SI (reg:SI 63) [664 S4 A32])

not that I can make any sense out of the above.  Note that the
testcase at
http://www.tat.physik.uni-tuebingen.de/~rguenth/gmp_test4.ii.gz
still "works" to reproduce also the above ICE.

Anything else to test?


Comment 33 dave 2004-05-27 15:36:29 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> Well, it has, in so far as reverting the patch fixes the problem.  Of
> course the patch may just uncover a latent problem - but that still makes
> rth (or the backporter) responsible of fixing the fallout.

I can't duplicate the ICE using the gmp_test4.ii testcase.  What were
the compilation options that triggered it?  They are not in the PR.
I have tried -O[1-3] with

dave@hiamlx:~/gcc_test> /home/dave/gnu/gcc-3.4/objdir/gcc/g++ -B/home/dave/gnu/gcc-3.4/objdir/gcc/ -v                 
Reading specs from /home/dave/gnu/gcc-3.4/objdir/gcc/specs
Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --enable-shared --disable-nls --prefix=/home/dave/opt/gnu/gcc/gcc-3.3.4 --enable-threads=posix --with-cpu=pentium3
Thread model: posix
gcc version 3.3.4 20040526 (prerelease)

I also compiled it without problem on hppa-linux.

Dave
Comment 34 Richard Biener 2004-05-27 15:45:39 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

On Thu, 27 May 2004, dave at hiauly1 dot hia dot nrc dot ca wrote:

>
> ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-05-27 15:36 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int
>
> > Well, it has, in so far as reverting the patch fixes the problem.  Of
> > course the patch may just uncover a latent problem - but that still makes
> > rth (or the backporter) responsible of fixing the fallout.
>
> I can't duplicate the ICE using the gmp_test4.ii testcase.  What were
> the compilation options that triggered it?  They are not in the PR.
> I have tried -O[1-3] with

Just -O2 -funroll-loops.
Comment 35 dave 2004-05-27 17:31:27 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> > I can't duplicate the ICE using the gmp_test4.ii testcase.  What were
> > the compilation options that triggered it?  They are not in the PR.
> > I have tried -O[1-3] with
> 
> Just -O2 -funroll-loops.

I did a new build with the patch below.  With this patch, I still can't
duplicate the ICE:

dave@hiamlx:~/gcc_test> /home/dave/gnu/gcc-3.4/objdir/gcc/g++ -B/home/dave/gnu/gcc-3.4/objdir/gcc/ -S -O2 -funroll-loops gmp_test4.ii
dave@hiamlx:~/gcc_test> /home/dave/gnu/gcc-3.4/objdir/gcc/g++ -B/home/dave/gnu/gcc-3.4/objdir/gcc/ -S -O2 -v                         
Reading specs from /home/dave/gnu/gcc-3.4/objdir/gcc/specs
Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --enable-shared --disable-nls --prefix=/home/dave/opt/gnu/gcc/gcc-3.3.4 --enable-threads=posix --enable-languages=c++ --disable-checking --enable-__cxa_atexit --disable-libunwind-exceptions
Thread model: posix
gcc version 3.3.4 20040526 (prerelease)

I'm retrying with an unmodified tree and the "-O2 -funroll-loops" option.

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

Index: alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.181.2.5
diff -u -3 -p -r1.181.2.5 alias.c
--- alias.c	8 May 2004 21:52:42 -0000	1.181.2.5
+++ alias.c	27 May 2004 17:12:34 -0000
@@ -2786,10 +2786,7 @@ init_alias_analysis ()
   reg_seen = (char *) xmalloc (reg_base_value_size);
   if (! reload_completed && flag_unroll_loops)
     {
-      /* ??? Why are we realloc'ing if we're just going to zero it?  */
-      alias_invariant = (rtx *)xrealloc (alias_invariant,
-					 reg_base_value_size * sizeof (rtx));
-      memset ((char *)alias_invariant, 0, reg_base_value_size * sizeof (rtx));
+      alias_invariant = ggc_calloc (reg_base_value_size, sizeof (rtx));
       alias_invariant_size = reg_base_value_size;
     }
 
@@ -2985,7 +2982,6 @@ end_alias_analysis ()
   reg_base_value_size = 0;
   if (alias_invariant)
     {
-      free (alias_invariant);
       alias_invariant = 0;
       alias_invariant_size = 0;
     }
Comment 36 dave 2004-05-27 18:48:47 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> I'm retrying with an unmodified tree and the "-O2 -funroll-loops" option.

Same result, I can't duplicate the ICE:

dave@hiamlx:~/gcc_test> /home/dave/gnu/gcc-3.4/objdir/gcc/g++ -B/home/dave/gnu/gcc-3.4/objdir/gcc/ -S -O2 -funroll-loops gmp_test4.ii
dave@hiamlx:~/gcc_test> /home/dave/gnu/gcc-3.4/objdir/gcc/g++ -B/home/dave/gnu/gcc-3.4/objdir/gcc/ -S -O2 -v
Reading specs from /home/dave/gnu/gcc-3.4/objdir/gcc/specs
Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --enable-shared --disable-nls --prefix=/home/dave/opt/gnu/gcc/gcc-3.3.4 --enable-threads=posix --enable-languages=c++ --disable-checking --enable-__cxa_atexit --disable-libunwind-exceptions
Thread model: posix
gcc version 3.3.4 20040527 (prerelease)

This a system running Suse 9.0.  The kernel is 2.4.23-bk3.

Dave
Comment 37 Eric Botcazou 2004-05-27 19:12:36 UTC
Did you use the same GC parameters as Richard, namely --param ggc-min-expand=100
--param ggc-min-heapsize=131072?
Comment 38 dave 2004-05-27 20:17:12 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> Did you use the same GC parameters as Richard, namely --param
> ggc-min-expand=100
> --param ggc-min-heapsize=131072?

No, but it compiles with these as well.  However, I was able to hit
a similar ICE building pooma-2.4.0:

Program received signal SIGSEGV, Segmentation fault.
0x08289805 in ggc_set_mark (p=0x8891450) at ../../gcc/gcc/ggc-page.c:525
525       L2 = LOOKUP_L2 (p);
(gdb) bt
#0  0x08289805 in ggc_set_mark (p=0x8891450) at ../../gcc/gcc/ggc-page.c:525
#1  0x080e0918 in gt_ggc_ma_alias_invariant (x_p=0x8891450) at gt-alias.h:47
#2  0x08167b30 in ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:124
#3  0x08289f07 in ggc_collect () at ../../gcc/gcc/ggc-page.c:1727
#4  0x080fe10d in cse_main (f=0x1, nregs=-1073748992, after_loop=1, file=0x0)
    at ../../gcc/gcc/cse.c:7250
#5  0x082705f0 in rest_of_compilation (decl=0x417c91c0)
    at ../../gcc/gcc/toplev.c:3059

(gdb) p alias_invariant
$4 = (rtx *) 0x8891450
(gdb) p p
$5 = (const void *) 0x8891450

Dave
Comment 39 dave 2004-05-27 20:45:34 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> No, but it compiles with these as well.  However, I was able to hit
> a similar ICE building pooma-2.4.0:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x08289805 in ggc_set_mark (p=0x8891450) at ../../gcc/gcc/ggc-page.c:525
> 525       L2 = LOOKUP_L2 (p);
> (gdb) bt
> #0  0x08289805 in ggc_set_mark (p=0x8891450) at ../../gcc/gcc/ggc-page.c:525
> #1  0x080e0918 in gt_ggc_ma_alias_invariant (x_p=0x8891450) at gt-alias.h:47
> #2  0x08167b30 in ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:124
> #3  0x08289f07 in ggc_collect () at ../../gcc/gcc/ggc-page.c:1727
> #4  0x080fe10d in cse_main (f=0x1, nregs=-1073748992, after_loop=1,
> file=0x0)
>     at ../../gcc/gcc/cse.c:7250
> #5  0x082705f0 in rest_of_compilation (decl=0x417c91c0)
>     at ../../gcc/gcc/toplev.c:3059
> 
> (gdb) p alias_invariant
> $4 = (rtx *) 0x8891450
> (gdb) p p
> $5 = (const void *) 0x8891450

This appears to be because alias_invariant was not GC allocated.  I
think the patch that I posted earlier today will fix this.  It's basically
the same as that applied to the trunk except that in 3.3 the arrays are
over allocated to allow for expansion during loop_optimize.

Dave
Comment 40 Gabriel Dos Reis 2004-05-28 00:15:45 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault

"dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org> writes:

| This appears to be because alias_invariant was not GC allocated.  I
| think the patch that I posted earlier today will fix this.  It's basically
| the same as that applied to the trunk except that in 3.3 the arrays are
| over allocated to allow for expansion during loop_optimize.

Thanks for the additional information.  Please could you give me a
link to the patch that you proposed for 3.3.x?  Thanks.

-- Gaby
Comment 41 dave 2004-05-28 01:34:01 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int

> | This appears to be because alias_invariant was not GC allocated.  I
> | think the patch that I posted earlier today will fix this.  It's basically
> | the same as that applied to the trunk except that in 3.3 the arrays are
> | over allocated to allow for expansion during loop_optimize.
> 
> Thanks for the additional information.  Please could you give me a
> link to the patch that you proposed for 3.3.x?  Thanks.

Here is the patch that I propose.  It uses ggc_alloc_cleared because
the multiplication is already done in init_alias_analysis.  I have
added the "rtx *" cast for K&R compatibility.

I have built the testcase provided with PR15660 and the current version
of the pooma-2.4.0 with -O2 -funroll-loops.  However, the triggering
of collection probably depends on the amount of memory in the test
machine.  So, Richard should test the patch and see if it resolves
his PR.

I've done a complete bootstrap with no regressions on hppa-unknown-linux-gnu.
A full build of all languages except treelang has just completed on
i686-pc-linux-gnu.  I will start a check.

A similar fix is needed 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-05-27  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	PR bootstrap/14671
	* alias.c (init_alias_analysis): Allocate alias_invariant array with
	ggc_alloc_cleared instead of xrealloc.
	(end_alias_analysis): Don't free alias_invariant.

Index: alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.181.2.5
diff -u -3 -p -r1.181.2.5 alias.c
--- alias.c	8 May 2004 21:52:42 -0000	1.181.2.5
+++ alias.c	27 May 2004 21:07:12 -0000
@@ -2786,10 +2786,8 @@ init_alias_analysis ()
   reg_seen = (char *) xmalloc (reg_base_value_size);
   if (! reload_completed && flag_unroll_loops)
     {
-      /* ??? Why are we realloc'ing if we're just going to zero it?  */
-      alias_invariant = (rtx *)xrealloc (alias_invariant,
-					 reg_base_value_size * sizeof (rtx));
-      memset ((char *)alias_invariant, 0, reg_base_value_size * sizeof (rtx));
+      alias_invariant = (rtx *) ggc_alloc_cleared (reg_base_value_size
+						   * sizeof (rtx));
       alias_invariant_size = reg_base_value_size;
     }
 
@@ -2985,7 +2983,6 @@ end_alias_analysis ()
   reg_base_value_size = 0;
   if (alias_invariant)
     {
-      free (alias_invariant);
       alias_invariant = 0;
       alias_invariant_size = 0;
     }
Comment 42 Gabriel Dos Reis 2004-05-28 03:05:03 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault

"dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org> writes:

| ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-05-28 01:34 -------
| Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int
| 
| > | This appears to be because alias_invariant was not GC allocated.  I
| > | think the patch that I posted earlier today will fix this.  It's basically
| > | the same as that applied to the trunk except that in 3.3 the arrays are
| > | over allocated to allow for expansion during loop_optimize.
| > 
| > Thanks for the additional information.  Please could you give me a
| > link to the patch that you proposed for 3.3.x?  Thanks.
| 
| Here is the patch that I propose.  It uses ggc_alloc_cleared because
| the multiplication is already done in init_alias_analysis.  I have
| added the "rtx *" cast for K&R compatibility.
| 
| I have built the testcase provided with PR15660 and the current version
| of the pooma-2.4.0 with -O2 -funroll-loops.  However, the triggering
| of collection probably depends on the amount of memory in the test
| machine.  So, Richard should test the patch and see if it resolves
| his PR.

Thanks for your time.

Richard --

  Please can you test the patch?

Thanks,

-- Gaby
Comment 43 Richard Biener 2004-05-28 07:30:56 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

On Thu, 27 May 2004, dave at hiauly1 dot hia dot nrc dot ca wrote:

>
> ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-05-27 18:48 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int
>
> > I'm retrying with an unmodified tree and the "-O2 -funroll-loops" option.
>
> Same result, I can't duplicate the ICE:
>
> dave@hiamlx:~/gcc_test> /home/dave/gnu/gcc-3.4/objdir/gcc/g++ -B/home/dave/gnu/gcc-3.4/objdir/gcc/ -S -O2 -funroll-loops gmp_test4.ii
> dave@hiamlx:~/gcc_test> /home/dave/gnu/gcc-3.4/objdir/gcc/g++ -B/home/dave/gnu/gcc-3.4/objdir/gcc/ -S -O2 -v
> Reading specs from /home/dave/gnu/gcc-3.4/objdir/gcc/specs
> Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld --enable-shared --disable-nls --prefix=/home/dave/opt/gnu/gcc/gcc-3.3.4 --enable-threads=posix --enable-languages=c++ --disable-checking --enable-__cxa_atexit --disable-libunwind-exceptions
> Thread model: posix
> gcc version 3.3.4 20040527 (prerelease)
>
> This a system running Suse 9.0.  The kernel is 2.4.23-bk3.

As this is GC related, try --param ggc-min-expand=100 --param
ggc-min-heapsize=131072, which is what gcc uses for me.

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
Comment 44 Richard Biener 2004-05-28 07:40:34 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

On Fri, 28 May 2004, dave at hiauly1 dot hia dot nrc dot ca wrote:

>
> ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-05-28 01:34 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int
>
> > | This appears to be because alias_invariant was not GC allocated.  I
> > | think the patch that I posted earlier today will fix this.  It's basically
> > | the same as that applied to the trunk except that in 3.3 the arrays are
> > | over allocated to allow for expansion during loop_optimize.
> >
> > Thanks for the additional information.  Please could you give me a
> > link to the patch that you proposed for 3.3.x?  Thanks.
>
> Here is the patch that I propose.  It uses ggc_alloc_cleared because
> the multiplication is already done in init_alias_analysis.  I have
> added the "rtx *" cast for K&R compatibility.
>
> I have built the testcase provided with PR15660 and the current version
> of the pooma-2.4.0 with -O2 -funroll-loops.  However, the triggering
> of collection probably depends on the amount of memory in the test
> machine.  So, Richard should test the patch and see if it resolves
> his PR.
>
> I've done a complete bootstrap with no regressions on hppa-unknown-linux-gnu.
> A full build of all languages except treelang has just completed on
> i686-pc-linux-gnu.  I will start a check.
>
> A similar fix is needed 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-05-27  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>
>
> 	PR bootstrap/14671
> 	* alias.c (init_alias_analysis): Allocate alias_invariant array with
> 	ggc_alloc_cleared instead of xrealloc.
> 	(end_alias_analysis): Don't free alias_invariant.
>
> Index: alias.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/alias.c,v
> retrieving revision 1.181.2.5
> diff -u -3 -p -r1.181.2.5 alias.c
> --- alias.c	8 May 2004 21:52:42 -0000	1.181.2.5
> +++ alias.c	27 May 2004 21:07:12 -0000
> @@ -2786,10 +2786,8 @@ init_alias_analysis ()
>    reg_seen = (char *) xmalloc (reg_base_value_size);
>    if (! reload_completed && flag_unroll_loops)
>      {
> -      /* ??? Why are we realloc'ing if we're just going to zero it?  */
> -      alias_invariant = (rtx *)xrealloc (alias_invariant,
> -					 reg_base_value_size * sizeof (rtx));
> -      memset ((char *)alias_invariant, 0, reg_base_value_size * sizeof (rtx));
> +      alias_invariant = (rtx *) ggc_alloc_cleared (reg_base_value_size
> +						   * sizeof (rtx));
>        alias_invariant_size = reg_base_value_size;
>      }
>
> @@ -2985,7 +2983,6 @@ end_alias_analysis ()
>    reg_base_value_size = 0;
>    if (alias_invariant)
>      {
> -      free (alias_invariant);
>        alias_invariant = 0;
>        alias_invariant_size = 0;
>      }

Duh, I had the following applied:

--- gcc/alias.c 8 May 2004 21:52:42 -0000       1.181.2.5
+++ gcc/alias.c 28 May 2004 07:32:23 -0000
@@ -2787,10 +2787,8 @@
   if (! reload_completed && flag_unroll_loops)
     {
       /* ??? Why are we realloc'ing if we're just going to zero it?  */
-      alias_invariant = (rtx *)xrealloc (alias_invariant,
-                                        reg_base_value_size * sizeof
(rtx));
-      memset ((char *)alias_invariant, 0, reg_base_value_size * sizeof
(rtx));
-      alias_invariant_size = reg_base_value_size;
+      alias_invariant = ggc_calloc (maxreg, sizeof (rtx));
+      alias_invariant_size = maxreg;
     }

   /* The basic idea is that each pass through this loop will use the
@@ -2985,7 +2983,6 @@
   reg_base_value_size = 0;
   if (alias_invariant)
     {
-      free (alias_invariant);
       alias_invariant = 0;
       alias_invariant_size = 0;
     }

I'll re-check with the patch above.  Unrelated, I have also applied
locally

--- gcc/loop.c  29 Jan 2004 04:42:15 -0000      1.433.2.13
+++ gcc/loop.c  28 May 2004 07:32:24 -0000
@@ -4924,6 +4924,9 @@
                                          gen_move_insn (v->dest_reg,
                                                         v->new_reg));

+         /* We must do this now because we just emitted a new set.  */
+         RTX_UNCHANGING_P (v->dest_reg) = 0;
+
          /* The original insn may have a REG_EQUAL note.  This note is
             now incorrect and may result in invalid substitutions later.
             The original insn is dead, but may be part of a libcall

(PR14671)

and from previous does-this-fix-it iterations

--- gcc/loop.h  17 May 2004 21:05:46 -0000      1.65.2.2
+++ gcc/loop.h  28 May 2004 07:32:25 -0000
@@ -49,9 +49,18 @@
   (INSN_UID (INSN) < max_uid_for_loop ? uid_luid[INSN_UID (INSN)] \
    : (abort (), -1))

-#define REGNO_FIRST_LUID(REGNO) uid_luid[REGNO_FIRST_UID (REGNO)]
-#define REGNO_LAST_LUID(REGNO) uid_luid[REGNO_LAST_UID (REGNO)]
-#define REGNO_LAST_NOTE_LUID(REGNO) uid_luid[REGNO_LAST_NOTE_UID (REGNO)]
+#define REGNO_FIRST_LUID(REGNO)                        \
+  (REGNO_FIRST_UID (REGNO) < max_uid_for_loop  \
+       ? uid_luid[REGNO_FIRST_UID (REGNO)]     \
+       : 0)
+#define REGNO_LAST_LUID(REGNO)                 \
+  (REGNO_LAST_UID (REGNO) < max_uid_for_loop   \
+       ? uid_luid[REGNO_LAST_UID (REGNO)]      \
+       : INT_MAX)
+#define REGNO_LAST_NOTE_LUID(REGNO)                 \
+  (REGNO_LAST_NOTE_UID (REGNO) < max_uid_for_loop   \
+       ? uid_luid[REGNO_LAST_NOTE_UID (REGNO)]      \
+       : INT_MAX)


 /* A "basic induction variable" or biv is a pseudo reg that is set
--- gcc/unroll.c        17 May 2004 21:05:48 -0000      1.184.2.9
+++ gcc/unroll.c        28 May 2004 07:32:25 -0000
@@ -2557,7 +2557,7 @@
       biv_final_value = 0;
       if (unroll_type != UNROLL_COMPLETELY
          && (loop->exit_count || unroll_type == UNROLL_NAIVE)
-         && (REGNO_LAST_LUID (bl->regno) >= INSN_LUID (loop->end)
+         && (REGNO_LAST_NOTE_LUID (bl->regno) >= INSN_LUID (loop->end)
              || ! bl->init_insn
              || INSN_UID (bl->init_insn) >= max_uid_for_loop
              || (REGNO_FIRST_LUID (bl->regno)
@@ -2754,7 +2754,7 @@
                      || (REGNO_FIRST_UID (REGNO (v->dest_reg))
                          != INSN_UID (XEXP (tem, 0)))))
              /* Line above always fails if INSN was moved by loop opt.
*/
-             || (REGNO_LAST_LUID (REGNO (v->dest_reg))
+             || (REGNO_LAST_NOTE_LUID (REGNO (v->dest_reg))
                  >= INSN_LUID (loop->end)))
          && ! (final_value = v->final_value))
        continue;

Comment 45 Richard Biener 2004-05-28 10:48:05 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491:
 internal compiler error: Segmentation fault

On Fri, 28 May 2004, gdr at integrable-solutions dot net wrote:

>
> ------- Additional Comments From gdr at integrable-solutions dot net  2004-05-28 03:05 -------
> Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault
>
> "dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org> writes:
>
> | ------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-05-28 01:34 -------
> | Subject: Re:  [3.3/3.4 regression] caller-save.c:491: int
> |
> | > | This appears to be because alias_invariant was not GC allocated.  I
> | > | think the patch that I posted earlier today will fix this.  It's basically
> | > | the same as that applied to the trunk except that in 3.3 the arrays are
> | > | over allocated to allow for expansion during loop_optimize.
> | >
> | > Thanks for the additional information.  Please could you give me a
> | > link to the patch that you proposed for 3.3.x?  Thanks.
> |
> | Here is the patch that I propose.  It uses ggc_alloc_cleared because
> | the multiplication is already done in init_alias_analysis.  I have
> | added the "rtx *" cast for K&R compatibility.
> |
> | I have built the testcase provided with PR15660 and the current version
> | of the pooma-2.4.0 with -O2 -funroll-loops.  However, the triggering
> | of collection probably depends on the amount of memory in the test
> | machine.  So, Richard should test the patch and see if it resolves
> | his PR.
>
> Thanks for your time.
>
> Richard --
>
>   Please can you test the patch?

It works.  Together with Erics (second) proposed patch to PR13653 POOMA
is now regression-free with gcc 3.3!

Thanks,

Richard.
Comment 46 Gabriel Dos Reis 2004-05-28 11:31:29 UTC
Subject: Re:  [3.3/3.4 regression] caller-save.c:491: internal compiler error: Segmentation fault

"rguenth at tat dot physik dot uni-tuebingen dot de" <gcc-bugzilla@gcc.gnu.org> writes:

[...]

| > Richard --
| >
| >   Please can you test the patch?
| 
| It works.  Together with Erics (second) proposed patch to PR13653 POOMA
| is now regression-free with gcc 3.3!

Wew!  Thanks to all of you.

Dave, please apply your patch. Eric, is your patch resolved with
Kenner and RTH? (they had some questions).

Thanks,

-- Gaby
Comment 47 Eric Botcazou 2004-05-28 11:55:38 UTC
It was actually Jeff and R.Kenner, and RTH replied to both.  But it would not
hurt to have a formal approval I think.
Comment 48 CVS Commits 2004-05-28 17:27:34 UTC
Subject: Bug 14671

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	danglin@gcc.gnu.org	2004-05-28 17:27:28

Modified files:
	gcc            : ChangeLog alias.c 

Log message:
	PR bootstrap/14671
	* alias.c (init_alias_analysis): Allocate alias_invariant array with
	ggc_alloc_cleared instead of xrealloc.
	(end_alias_analysis): Don't free alias_invariant.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.986&r2=1.16114.2.987
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/alias.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.181.2.5&r2=1.181.2.6

Comment 49 Andrew Pinski 2004-05-28 17:32:51 UTC
*** Bug 15677 has been marked as a duplicate of this bug. ***
Comment 50 Andrew Pinski 2004-05-28 17:36:23 UTC
If I read this correctly this is really also needed for 3.4.x also.
Comment 51 dave 2004-05-28 17:55:19 UTC
Subject: Re:  [3.4 regression] caller-save.c:491: interna

> If I read this correctly this is really also needed for 3.4.x also.

Yes, but I will need Mark's approval.

Dave
Comment 52 Mark Mitchell 2004-05-28 22:58:03 UTC
Dave --

This patch is OK for GCC 3.4.1.  Please check it in!

Thanks,

-- Mark
Comment 53 CVS Commits 2004-05-29 00:02:41 UTC
Subject: Bug 14671

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	danglin@gcc.gnu.org	2004-05-29 00:02:15

Modified files:
	gcc            : ChangeLog alias.c 

Log message:
	PR bootstrap/14671
	* alias.c (init_alias_analysis): Allocate alias_invariant array with
	ggc_calloc instead of xrealloc.
	(end_alias_analysis): Don't free alias_invariant.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.455&r2=2.2326.2.456
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/alias.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.209.2.5&r2=1.209.2.6

Comment 54 Andrew Pinski 2004-05-29 00:05:19 UTC
Fixed.  Thanks David for applying the patch and testing it.
Comment 55 dave 2004-05-29 00:06:08 UTC
Subject: Re:  [3.4 regression] caller-save.c:491: interna

> This patch is OK for GCC 3.4.1.  Please check it in!

3.4 is a little bit different.  This is what I committed after testing
on hppa-unknown-linux-gnu with a bootstrap with -funroll-loops added to
BOOT_CFLAGS.

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

2004-05-28  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

	PR bootstrap/14671
	* alias.c (init_alias_analysis): Allocate alias_invariant array with
	ggc_calloc instead of xrealloc.
	(end_alias_analysis): Don't free alias_invariant.

Index: alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.209.2.5
diff -u -3 -p -r1.209.2.5 alias.c
--- alias.c	21 Apr 2004 19:52:36 -0000	1.209.2.5
+++ alias.c	28 May 2004 19:04:36 -0000
@@ -2816,10 +2816,7 @@ init_alias_analysis (void)
   reg_seen = xmalloc (maxreg);
   if (! reload_completed && flag_old_unroll_loops)
     {
-      /* ??? Why are we realloc'ing if we're just going to zero it?  */
-      alias_invariant = xrealloc (alias_invariant,
-				  maxreg * sizeof (rtx));
-      memset (alias_invariant, 0, maxreg * sizeof (rtx));
+      alias_invariant = ggc_calloc (maxreg, sizeof (rtx));
       alias_invariant_size = maxreg;
     }
 
@@ -3019,7 +3016,6 @@ end_alias_analysis (void)
   reg_known_equiv_p = 0;
   if (alias_invariant)
     {
-      free (alias_invariant);
       alias_invariant = 0;
       alias_invariant_size = 0;
     }
Comment 56 dave 2004-05-29 00:16:20 UTC
Subject: Re:  [3.4 regression] caller-save.c:491: interna

> Fixed.  Thanks David for applying the patch and testing it.

Wow, marked fixed less than three minutes after the commit reply.
Andrew, I'm beginning to think that you are a computer project at UC ;)

Dave