Same on i586-linux, it's a regalloc/reload issue.

Vlad, caused by the IRA merge?

> Vlad, caused by the IRA merge?

Yes, see my message on gcc@.  But I cannot reproduce it anymore today (r139820)
on Linux, can you on FreeBSD?

(In reply to comment #3)
> > Vlad, caused by the IRA merge?
> 
> Yes, see my message on gcc@.  But I cannot reproduce it anymore today (r139820)
> on Linux, can you on FreeBSD?
> 

It is not fixed on FreeBSD.  I sometimes also see

checking for i386-unknown-freebsd8.0-gcc... /usr/home/kargl/gcc/obj/./gcc/xgcc -B/usr/home/kargl/gcc/obj/./gcc/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include
checking for suffix of object files... configure: error: in `/usr/home/kargl/gcc/obj/i386-unknown-freebsd8.0/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[2]: *** [configure-stage2-target-libgcc] Error 1
gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj'
gmake: *** [bootstrap] Error 2

In looking at i386-unknown-freebsd8.0/libgcc/config.log, I find
configure:2415: /usr/home/kargl/gcc/obj/./gcc/xgcc -B/usr/home/kargl/gcc/obj/./gcc/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include -o conftest -g -O2     conftest.c  >&5
conftest.c: In function 'main':
conftest.c:16: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:2418: $? = 1
configure:2590: checking for suffix of object files
configure:2611: /usr/home/kargl/gcc/obj/./gcc/xgcc -B/usr/home/kargl/gcc/obj/./gcc/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/ -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include -c -g -O2    conftest.c >&5
conftest.c: In function 'main':
conftest.c:16: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:2614: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| 
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:2627: error: in `/usr/home/kargl/gcc/obj/i386-unknown-freebsd8.0/libgcc':
configure:2629: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

It might be an IRA bug.

Could you try two latest patches

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02377.html

I have not got an approval for them yet so they are not in the mainline yet.

(In reply to comment #5)
> It might be an IRA bug.
> 
> Could you try two latest patches
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02377.html
> 
> I have not got an approval for them yet so they are not in the mainline yet.

It's definitely a IRA realted issue.  I reverted your 3 IRA
patches
 
svn merge -r 139770:139769
svn merge -r 139769:139768
svn merge -r 139590:139589

My build just finished and I'm now doing a 'gmake check-gfortran' to
see if there are any regressions.  

I'll try your patches when the regression test completes and get back to
you with a yeah or nay.

Added my other email address

Reverted my back out of the 3 patches mentioned in comment #6
and update to top of tree, which was revision 139848.  If I 
read the threads pointed to in comment #5, I already had the
patches in my tree.  It still broken.

Here's a backtrace.

mobile:kargl[281] gdb /usr/home/kargl/gcc/obj/./gcc/cc1
GNU gdb 6.1.1 [FreeBSD]
(gdb) run b.c
Starting program: /usr/home/kargl/gcc/obj/gcc/cc1 b.c
 main
Analyzing compilation unit
Performing interprocedural optimizations
 <visibility> <early_local_cleanups>
Program received signal SIGSEGV, Segmentation fault.
initialize_inline_failed (node=0x0) at ../../gcc4x/gcc/cgraphbuild.c:90
90        for (e = node->callers; e; e = e->next_caller)
(gdb) bt
#0  initialize_inline_failed (node=0x0) at ../../gcc4x/gcc/cgraphbuild.c:90
#1  0x084315c9 in rebuild_cgraph_edges () at ../../gcc4x/gcc/cgraphbuild.c:258
#2  0x08238fe1 in execute_one_pass (pass=0x8a37100) at ../../gcc4x/gcc/passes.c:1277
#3  0x08239218 in execute_pass_list (pass=0x8a37100) at ../../gcc4x/gcc/passes.c:1325
#4  0x082394d0 in execute_ipa_pass_list (pass=0x0) at ../../gcc4x/gcc/passes.c:890
#5  0x08433f44 in cgraph_optimize () at ../../gcc4x/gcc/cgraphunit.c:1234
#6  0x0805ab1b in c_write_global_declarations () at ../../gcc4x/gcc/c-decl.c:8080
#7  0x082aba1b in toplev_main (argc=2, argv=0xbfbfe6fc) at ../../gcc4x/gcc/toplev.c:979
#8  0x0804aee9 in _start ()
#9  0x00000002 in ?? ()

I'll leave my current tree alone, so if you anything else just ask.

Subject: Re:  Bootstrap failure due to __muldi3

All,

From the backtrace I very doubt this is a IRA issue.

I looks to be related to the recent IPA/CGRAPG changes
so it's one for Honza to look at

Cheers
Graham

> It is not fixed on FreeBSD.  I sometimes also see
> 
> checking for i386-unknown-freebsd8.0-gcc... /usr/home/kargl/gcc/obj/./gcc/xgcc
> -B/usr/home/kargl/gcc/obj/./gcc/
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem
> /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem
> /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include
> checking for suffix of object files... configure: error: in
> `/usr/home/kargl/gcc/obj/i386-unknown-freebsd8.0/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> gmake[2]: *** [configure-stage2-target-libgcc] Error 1
> gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake[1]: *** [stage2-bubble] Error 2
> gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake: *** [bootstrap] Error 2

Yes, I got that on Linux too at rev 139835.  Everybody was rushing patches so
there might be multiple issues on top of each other.

> From the backtrace I very doubt this is a IRA issue.

The backtrace is for another problem, the _muldi3 issue is a miscompilation of
gimple.c:gimple_build_asm_vec by the new regalloc/reload.

Reconfirmed with failure mode from comment #4 on i586-linux at r139863.

I'm going to investigate.

Subject: Re:  Bootstrap failure due to __muldi3

On Mon, Sep 01, 2008 at 10:30:27AM -0000, graham dot stott at btinternet dot com wrote:
> 
> ------- Comment #10 from graham dot stott at btinternet dot com  2008-09-01 10:30 -------
> 
> From the backtrace I very doubt this is a IRA issue.
> 
> I looks to be related to the recent IPA/CGRAPG changes
> so it's one for Honza to look at
> 

While Vlad's IRA patches may not be directly responsible, the
evidence shows that if I revert Vlad's patches my tree then
builds.  I'll put Vlad's stuff back into my tree and see
if I can locate if it is one of Honza's patches.

> checking for i386-unknown-freebsd8.0-gcc... /usr/home/kargl/gcc/obj/./gcc/xgcc
> -B/usr/home/kargl/gcc/obj/./gcc/
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/bin/
> -B/usr/home/kargl/work/i386-unknown-freebsd8.0/lib/ -isystem
> /usr/home/kargl/work/i386-unknown-freebsd8.0/include -isystem
> /usr/home/kargl/work/i386-unknown-freebsd8.0/sys-include
> checking for suffix of object files... configure: error: in
> `/usr/home/kargl/gcc/obj/i386-unknown-freebsd8.0/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> gmake[2]: *** [configure-stage2-target-libgcc] Error 1
> gmake[2]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake[1]: *** [stage2-bubble] Error 2
> gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj'
> gmake: *** [bootstrap] Error 2

It's the same issue as the __muldi3 thing.  cgraphbuild.c:rebuild_cgraph_edges
is miscompiled at -O2 -fomit-frame-pointer by regalloc/reload because of some
problem with elimination offsets.  I think -fomit-frame-pointer is somewhat
broken since the IRA merge.  I'll attach testcases tomorrow.

Created attachment 16189 [details]
Simplified preprocessed source

It's still big, but it yields a 353-line assembly file.

Compile with -O2 -fomit-frame-pointer -mtune=pentium.  In rebuild_cgraph_edges:

	call	cgraph_node
	movl	%eax, 32(%esp)

[...]

	movl	48(%esp), %eax
	call	initialize_inline_failed

The offset against %esp should be the same.

> The offset against %esp should be the same.

Actually it should be adjusted to the value of %esp:

rebuild_cgraph_edges:
	pushl	%ebp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	subl	$56, %esp
	pushl	current_function_decl
	call	cgraph_node
	movl	%eax, 32(%esp)

[...]

.L21:
	movl	48(%esp), %eax
	call	initialize_inline_failed
	movl	48(%esp), %edx
	cmpl	$0, 76(%edx)
	jne	.L53
	addl	$44, %esp
	xorl	%eax, %eax
	popl	%ebx
	popl	%esi
	popl	%edi
	popl	%ebp
	ret

so 16(%esp) instead of 48(%esp) if the stack adjustments are correct.

I've looked at the cgraphbuild.i code and I think something is wrong with inlining.  There are two paths achieving L21 with different stack adjustments.  Here is the code.  I marked insns adjusting SP by -> and the two insns should refer to the same location by !

.globl rebuild_cgraph_edges
	.type	rebuild_cgraph_edges, @function
rebuild_cgraph_edges:
	pushl	%ebp
	pushl	%edi
	pushl	%esi
	pushl	%ebx
	subl	$56, %esp
	movl	current_function_decl, %edx
	pushl	%edx
	call	cgraph_node
!	movl	%eax, 32(%esp)
	movl	%eax, (%esp)
	call	cgraph_node_remove_callees
	movl	cfun, %eax
	movl	4(%eax), %ecx
	movl	32(%esp), %edi
-->	addl	$16, %esp
	movl	(%ecx), %edx
	movl	36(%edx), %ebx
	movl	40(%edx), %esi
	movl	%esi, 100(%edi)
	movl	%ebx, 96(%edi)
	movl	28(%edx), %edi
	cmpl	4(%ecx), %edi
	je	.L21
...
.L31:
	movl	28(%eax), %edx
	movl	%edx, 12(%esp)
	cmpw	$29, (%edx)
	jne	.L50
	cmpl	$9, tree_code_type+480
	je	.L51
	movl	28(%esp), %edx
	testl	%edx, %edx
	jle	.L52
	movl	48(%edi), %eax
	movl	%eax, 8(%esp)
--->	subl	$12, %esp
	pushl	%edi
	call	compute_call_stmt_bb_frequency
	movl	%eax, %ebp
	popl	%eax
	movl	36(%edi), %edx
	movl	40(%edi), %ecx
	movl	24(%esp), %eax
	pushl	%eax
	movl	%edx, 20(%esp)
	movl	%ecx, 16(%esp)
	call	cgraph_node
--->	addl	$12, %esp
	movl	12(%esp), %edx
	pushl	%edx
	pushl	%ebp
	movl	16(%esp), %edx
	movl	12(%esp), %ecx
	pushl	%ecx
	pushl	%edx
	pushl	%esi
	pushl	%eax
	movl	44(%esp), %ebp
	pushl	%ebp
	call	cgraph_create_edge
	movl	8(%ebx), %ebx
-->	addl	$32, %esp
	testl	%ebx, %ebx
	jne	.L42
	.p2align 4,,7
	.p2align 3
.L45:
	movl	cfun, %eax
.L22:
	movl	4(%eax), %edx
	movl	28(%edi), %edi
	cmpl	%edi, 4(%edx)
	jne	.L41
.L21:
!	movl	48(%esp), %eax
	call	initialize_inline_failed
...

> I've looked at the cgraphbuild.i code and I think something is wrong with
> inlining.  There are two paths achieving L21 with different stack adjustments. 
> Here is the code.  I marked insns adjusting SP by -> and the two insns should
> refer to the same location by !

Isn't that supposed to be detected by reload?

/* For each label, we record the offset of each elimination.  If we reach
   a label by more than one path and an offset differs, we cannot do the
   elimination.  This information is indexed by the difference of the
   number of the label and the first label number.  We can't offset the
   pointer itself as this can cause problems on machines with segmented
   memory.  The first table is an array of flags that records whether we
   have yet encountered a label and the second table is an array of arrays,
   one entry in the latter array for each elimination.  */

static int first_label_num;
static char *offsets_known_at;
static HOST_WIDE_INT (*offsets_at)[NUM_ELIMINABLE_REGS];

/* This function handles the tracking of elimination offsets around branches.

   X is a piece of RTL being scanned.

   INSN is the insn that it came from, if any.

   INITIAL_P is nonzero if we are to set the offset to be the initial
   offset and zero if we are setting the offset of the label to be the
   current offset.  */

static void
set_label_offsets (rtx x, rtx insn, int initial_p)
{
  enum rtx_code code = GET_CODE (x);
  rtx tem;
  unsigned int i;
  struct elim_table *p;

  switch (code)
    {
    case LABEL_REF:
      if (LABEL_REF_NONLOCAL_P (x))
	return;

      x = XEXP (x, 0);

      /* ... fall through ...  */

    case CODE_LABEL:
      /* If we know nothing about this label, set the desired offsets.  Note
	 that this sets the offset at a label to be the offset before a label
	 if we don't know anything about the label.  This is not correct for
	 the label after a BARRIER, but is the best guess we can make.  If
	 we guessed wrong, we will suppress an elimination that might have
	 been possible had we been able to guess correctly.  */

      if (! offsets_known_at[CODE_LABEL_NUMBER (x) - first_label_num])
	{
	  for (i = 0; i < NUM_ELIMINABLE_REGS; i++)
	    offsets_at[CODE_LABEL_NUMBER (x) - first_label_num][i]
	      = (initial_p ? reg_eliminate[i].initial_offset
		 : reg_eliminate[i].offset);
	  offsets_known_at[CODE_LABEL_NUMBER (x) - first_label_num] = 1;
	}

      /* Otherwise, if this is the definition of a label and it is
	 preceded by a BARRIER, set our offsets to the known offset of
	 that label.  */

      else if (x == insn
	       && (tem = prev_nonnote_insn (insn)) != 0
	       && BARRIER_P (tem))
	set_offsets_for_label (insn);
      else
	/* If neither of the above cases is true, compare each offset
	   with those previously recorded and suppress any eliminations
	   where the offsets disagree.  */

	for (i = 0; i < NUM_ELIMINABLE_REGS; i++)
	  if (offsets_at[CODE_LABEL_NUMBER (x) - first_label_num][i]
	      != (initial_p ? reg_eliminate[i].initial_offset
		  : reg_eliminate[i].offset))
	    reg_eliminate[i].can_eliminate = 0;

      return;

Isn't that supposed to be detected by reload?

Yea, right.  I missed that.  Eric, sorry for to be in hurry with the wrong response.

I am still working on the issue.  I hope to find a solution today or tomorrow.

(In reply to comment #15)
> It's the same issue as the __muldi3 thing.  cgraphbuild.c:rebuild_cgraph_edges
> is miscompiled at -O2 -fomit-frame-pointer by regalloc/reload because of some
> problem with elimination offsets.  I think -fomit-frame-pointer is somewhat
> broken since the IRA merge.  I'll attach testcases tomorrow.
> 

-fomit-frame-pointer is broken due to IRA merge. On Linux/ia32, there are

+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test

Remove -fomit-frame-pointer, they pass.

(In reply to comment #21)
> -fomit-frame-pointer is broken due to IRA merge. On Linux/ia32, there are

I get those on i386-darwin also.

On powerpc-apple-darwin9 revision 139912, I get:

...
/opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/powerpc-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/powerpc-apple-darwin9/sys-include -g -O2 -m64 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include  -Wa,-force_cpusubtype_ALL -pipe -mmacosx-version-min=10.4 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc -I../../../../gcc-4.4-work/libgcc -I../../../../gcc-4.4-work/libgcc/. -I../../../../gcc-4.4-work/libgcc/../gcc -I../../../../gcc-4.4-work/libgcc/../include  -DHAVE_CC_TLS -o _cmpdi2.o -MT _cmpdi2.o -MD -MP -MF _cmpdi2.dep -DL_cmpdi2 -c ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c \
	  -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c: In function '__cmpti2':
../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c:1151: internal compiler error: in ei_next, at basic-block.h:735
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[5]: *** [_cmpdi2.o] Error 1
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all-stage2-target-libgcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

Is this the same bug?

(In reply to comment #23)
> ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c: In function '__cmpti2':
> ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c:1151: internal compiler error:
> in ei_next, at basic-block.h:735

I see the same on arm.

   The problem is in sorting insn chains according to their
 frequencies to get a better reloads for most frequently executed
 insns.  This very simple optimization was introduced on IRA branch.
 Correct updating elimination offsets in reload needs original insn
 chain order.  I see two solutions of the problem:

o Restore evaluation of elimination offsets by using original order of
  insn chains.  It means move of sorting insn chains to function
  calculate_needs_all_insns and process offsets there before sorting.
  It also needs to save elimination offsets not only at code labels
  (as it now) but at any BB end start.  So it complicates
  significantly this very simple optimization and makes it even slower
  because we need sort insn chain on each reload iteration (not once
  as it now).

o Just remove sorting of insn chain.  I've checked the optimization
  impact on SPEC2000 for x86 and found it is not significant (about
  0.1% improvement on SPECINT2000 which is in measurement error range
  and 0.02% codes size decrease on SPECFP2000).  It should speed up
  the compiler although in reality I did not find a visible speedup.

After some thinking, I've decided to stic to the 2nd solution.

The patch solving the problem will follow soon.

Subject: Bug 37296

Author: vmakarov
Date: Wed Sep  3 19:49:30 2008
New Revision: 139948

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139948
Log:
2008-09-03  Vladimir Makarov  <vmakarov@redhat.com>

	PR rtl-opt/37296

	* ira-int.h (ira_sort_insn_chain): Remove.

	* ira.c (basic_block_order_nums, chain_insn_order,
	chain_freq_compare, chain_bb_compare, ira_sort_insn_chain): Remove.
	(ira): Don't call ira_sort_insn_chain.

	* reload1.c (reload): Don't call ira_sort_insn_chain.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira.c
    trunk/gcc/ira.h
    trunk/gcc/reload1.c

I now get on i586-linux at revision 139953

/home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/ -B/home/eric/install/gcc/i586-suse-linux/bin/ -B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem /home/eric/install/gcc/i586-suse-linux/include -isystem /home/eric/install/gcc/i586-suse-linux/sys-include -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I/home/eric/svn/gcc/libgcc -I/home/eric/svn/gcc/libgcc/. -I/home/eric/svn/gcc/libgcc/../gcc -I/home/eric/svn/gcc/libgcc/../include -I/home/eric/svn/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _popcountdi2.o -MT _popcountdi2.o -MD -MP -MF _popcountdi2.dep -DL_popcountdi2 -c /home/eric/svn/gcc/libgcc/../gcc/libgcc2.c \
          -fvisibility=hidden -DHIDE_EXPORTS
/home/eric/svn/gcc/libgcc/../gcc/libgcc2.c: In function '__popcountdi2':
/home/eric/svn/gcc/libgcc/../gcc/libgcc2.c:813: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [_popcountdi2.o] Error 1
make[3]: Leaving directory `/home/eric/build/gcc/native32/i586-suse-linux/libgcc'
make[2]: *** [all-stage2-target-libgcc] Error 2
make[2]: Leaving directory `/home/eric/build/gcc/native32'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/eric/build/gcc/native32'
make: *** [all] Error 2

I'll investigate tomorrow.

(In reply to comment #27)
> I now get on i586-linux at revision 139953
> 
> 
> I'll investigate tomorrow.
> 

Can you try ira-merge branch? It will help determine if it is caused
by IRA merge. Thanks.

Subject: Re:  [4.4 Regression] Bootstrap failure compiling libgcc

On Thu, Sep 04, 2008 at 05:53:28AM -0000, hjl dot tools at gmail dot com wrote:
> 
> 
> ------- Comment #28 from hjl dot tools at gmail dot com  2008-09-04 05:53 -------
> (In reply to comment #27)
> > I now get on i586-linux at revision 139953
> > 
> > I'll investigate tomorrow.
> > 
> 
> Can you try ira-merge branch? It will help determine if it is caused
> by IRA merge. Thanks.
> 
> 

HJ,

I think you meant to respond to Eric instead of me.  Vlad's
patch fixed the original problem for me and Eric, but Eric
is now see a new problem.

(In reply to comment #29)
> Subject: Re:  [4.4 Regression] Bootstrap failure compiling libgcc
> 
> I think you meant to respond to Eric instead of me.  Vlad's
> patch fixed the original problem for me and Eric, but Eric
> is now see a new problem.
> 

ira-merge branch has additional IRA fixes which may solve Eric's
problem if it is caused by IRA merge. I'd like to make sure that
his problem isn't IRA related.

I tried i586-linux with ira-merge branch. It built libgcc fine.
So the problem is either fixed on ira-merge branch or it isn't
caused by IRA merge.

> I tried i586-linux with ira-merge branch. It built libgcc fine.
> So the problem is either fixed on ira-merge branch or it isn't
> caused by IRA merge.

Or isn't exposed on that branch.

It's a stack slot reuse problem during RA compiling df-scan.c.  Since it's not
related to this PR, I'm closing it and I'll open a new one.

*** Bug 37422 has been marked as a duplicate of this bug. ***