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.
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.
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.
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].
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.
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
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
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
Dave, can you confirm whether or not this PR is fixed?
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 ();
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. */
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
Fixed by <http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02057.html> on trunk.
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
The backport to the 3.3 branch causes regressions in the POOMA testsuite on x86.
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
*** Bug 15660 has been marked as a duplicate of this bug. ***
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.
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.]
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
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.
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
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.
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
> 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.
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.
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
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
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
Just confirming this.
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.
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; }
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?
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
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.
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; }
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
Did you use the same GC parameters as Richard, namely --param ggc-min-expand=100 --param ggc-min-heapsize=131072?
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
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
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
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; }
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
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/
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;
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.
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
It was actually Jeff and R.Kenner, and RTH replied to both. But it would not hurt to have a formal approval I think.
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
*** Bug 15677 has been marked as a duplicate of this bug. ***
If I read this correctly this is really also needed for 3.4.x also.
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
Dave -- This patch is OK for GCC 3.4.1. Please check it in! Thanks, -- Mark
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
Fixed. Thanks David for applying the patch and testing it.
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; }
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