[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-11-13 Thread jakub at gcc dot gnu dot org


--- Comment #33 from jakub at gcc dot gnu dot org  2008-11-13 16:00 ---
*** Bug 37422 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-04 Thread ebotcazou at gcc dot gnu dot org


--- Comment #32 from ebotcazou at gcc dot gnu dot org  2008-09-04 19:30 
---
> 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.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-04 Thread hjl dot tools at gmail dot com


--- Comment #31 from hjl dot tools at gmail dot com  2008-09-04 14:53 
---
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-04 Thread hjl dot tools at gmail dot com


--- Comment #30 from hjl dot tools at gmail dot com  2008-09-04 13:07 
---
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread sgk at troutmask dot apl dot washington dot edu


--- Comment #29 from sgk at troutmask dot apl dot washington dot edu  
2008-09-04 06:15 ---
Subject: Re:  [4.4 Regression] Bootstrap failure compiling libgcc

On Thu, Sep 04, 2008 at 05:53:28AM -, 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread hjl dot tools at gmail dot com


--- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread ebotcazou at gcc dot gnu dot org


--- Comment #27 from ebotcazou at gcc dot gnu dot org  2008-09-03 21:05 
---
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  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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread vmakarov at gcc dot gnu dot org


--- Comment #26 from vmakarov at gcc dot gnu dot org  2008-09-03 19:50 
---
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  <[EMAIL PROTECTED]>

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread vmakarov at redhat dot com


--- Comment #25 from vmakarov at redhat dot com  2008-09-03 15:36 ---
   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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread tbm at cyrius dot com


--- Comment #24 from tbm at cyrius dot com  2008-09-03 07:56 ---
(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.


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||tbm at cyrius dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread dominiq at lps dot ens dot fr


--- Comment #23 from dominiq at lps dot ens dot fr  2008-09-03 05:22 ---
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  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?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread pinskia at gcc dot gnu dot org


--- Comment #22 from pinskia at gcc dot gnu dot org  2008-09-03 00:42 
---
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread hjl dot tools at gmail dot com


--- Comment #21 from hjl dot tools at gmail dot com  2008-09-03 00:27 
---
(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.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread vmakarov at redhat dot com


--- Comment #20 from vmakarov at redhat dot com  2008-09-02 18:13 ---
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread ebotcazou at gcc dot gnu dot org


--- Comment #19 from ebotcazou at gcc dot gnu dot org  2008-09-02 17:35 
---
> 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;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread vmakarov at redhat dot com


--- Comment #18 from vmakarov at redhat dot com  2008-09-02 17:29 ---
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
movlcurrent_function_decl, %edx
pushl   %edx
callcgraph_node
!   movl%eax, 32(%esp)
movl%eax, (%esp)
callcgraph_node_remove_callees
movlcfun, %eax
movl4(%eax), %ecx
movl32(%esp), %edi
--> addl$16, %esp
movl(%ecx), %edx
movl36(%edx), %ebx
movl40(%edx), %esi
movl%esi, 100(%edi)
movl%ebx, 96(%edi)
movl28(%edx), %edi
cmpl4(%ecx), %edi
je  .L21
...
.L31:
movl28(%eax), %edx
movl%edx, 12(%esp)
cmpw$29, (%edx)
jne .L50
cmpl$9, tree_code_type+480
je  .L51
movl28(%esp), %edx
testl   %edx, %edx
jle .L52
movl48(%edi), %eax
movl%eax, 8(%esp)
--->subl$12, %esp
pushl   %edi
callcompute_call_stmt_bb_frequency
movl%eax, %ebp
popl%eax
movl36(%edi), %edx
movl40(%edi), %ecx
movl24(%esp), %eax
pushl   %eax
movl%edx, 20(%esp)
movl%ecx, 16(%esp)
callcgraph_node
--->addl$12, %esp
movl12(%esp), %edx
pushl   %edx
pushl   %ebp
movl16(%esp), %edx
movl12(%esp), %ecx
pushl   %ecx
pushl   %edx
pushl   %esi
pushl   %eax
movl44(%esp), %ebp
pushl   %ebp
callcgraph_create_edge
movl8(%ebx), %ebx
--> addl$32, %esp
testl   %ebx, %ebx
jne .L42
.p2align 4,,7
.p2align 3
.L45:
movlcfun, %eax
.L22:
movl4(%eax), %edx
movl28(%edi), %edi
cmpl%edi, 4(%edx)
jne .L41
.L21:
!   movl48(%esp), %eax
callinitialize_inline_failed
...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread ebotcazou at gcc dot gnu dot org


--- Comment #17 from ebotcazou at gcc dot gnu dot org  2008-09-02 13:26 
---
> 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
callcgraph_node
movl%eax, 32(%esp)

[...]

.L21:
movl48(%esp), %eax
callinitialize_inline_failed
movl48(%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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-02 Thread ebotcazou at gcc dot gnu dot org


--- Comment #16 from ebotcazou at gcc dot gnu dot org  2008-09-02 10:17 
---
Created an attachment (id=16189)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16189&action=view)
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:

callcgraph_node
movl%eax, 32(%esp)

[...]

movl48(%esp), %eax
callinitialize_inline_failed

The offset against %esp should be the same.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-01 Thread ebotcazou at gcc dot gnu dot org


--- Comment #15 from ebotcazou at gcc dot gnu dot org  2008-09-01 21:46 
---
> 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-01 Thread sgk at troutmask dot apl dot washington dot edu


--- Comment #14 from sgk at troutmask dot apl dot washington dot edu  
2008-09-01 16:56 ---
Subject: Re:  Bootstrap failure due to __muldi3

On Mon, Sep 01, 2008 at 10:30:27AM -, 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-01 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-01 Thread ebotcazou at gcc dot gnu dot org


--- Comment #13 from ebotcazou at gcc dot gnu dot org  2008-09-01 13:40 
---
Reconfirmed with failure mode from comment #4 on i586-linux at r139863.

I'm going to investigate.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-09-01 13:03:01 |2008-09-01 13:40:06
   date||
Summary|[4.4 Regression] Bootstrap  |[4.4 Regression] Bootstrap
   |failure due to __muldi3 |failure compiling libgcc
   Target Milestone|4.4.0   |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296