[Bug bootstrap/42157] New: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions

[Bug bootstrap/42157] New: [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions

[ro at gcc dot gnu dot org]

While building current mainline (rev 154216) again after half a year, the
bootstrap
aborted while building the stage 1 libgcc:

/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/vol/gcc/src/gcc-dist/libgcc/../gcc/libgcc2.c:562:1: 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]: *** [_muldi3.o] Error 1

Running cc1 under gdb reveals

(gdb) run -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mno-synci
-auxbase-strip _muldi3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-version -o libgcc2.s
Starting program:
/tmp_mnt/vol/gcc/obj/gcc-4.5.0-20091116/5.3-gcc/mips-sgi-irix5.3/libgcc/cc1
-fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mno-synci -auxbase-strip
_muldi3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -o
libgcc2.s
GNU C (GCC) version 4.5.0 20091116 (experimental) [trunk revision 154216]
(mips-sgi-irix5.3)
        compiled by GNU C version 4.1.1, GMP version 4.2.1, MPFR version 2.3.2,
MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.5.0 20091116 (experimental) [trunk revision 154216]
(mips-sgi-irix5.3)
        compiled by GNU C version 4.1.1, GMP version 4.2.1, MPFR version 2.3.2,
MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 23aff50e67c559603acf00c443e2c073

Program received signal SIGSEGV, Segmentation fault.
0x014a2e48 in compare_access_positions (a=0x10292084, b=0x1029208c)
    at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1106
(gdb) p f1
$1 = (const access_p) 0x20
(gdb) p f2
$2 = (const access_p) 0x10291d80
(gdb) where
#0  0x014a2e48 in compare_access_positions (a=0x10292084, b=0x1029208c)
    at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1106
#1  0x0fac4254 in qsort () at qsort.c:94
#2  0x014a610c in sort_and_splice_var_accesses (var=0x1a98b40)
    at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1407
#3  0x014a9050 in analyze_all_variable_accesses ()
    at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:1875
#4  0x014ad7dc in perform_intra_sra ()
    at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:2568
#5  0x014ada50 in early_intra_sra ()
    at /vol/gcc/src/gcc-dist/gcc/tree-sra.c:2597
#6  0x00d17cec in execute_one_pass (pass=0x10180324)
    at /vol/gcc/src/gcc-dist/gcc/passes.c:1522
#7  0x00d1853c in execute_pass_list (pass=0x10180324)
    at /vol/gcc/src/gcc-dist/gcc/passes.c:1577
#8  0x00d18584 in execute_pass_list (pass=0x1017fe38)
    at /vol/gcc/src/gcc-dist/gcc/passes.c:1578
#9  0x00d16064 in do_per_function_toporder (
    callback=0xd184a4 <execute_pass_list>, data=0x1018cb48)
    at /vol/gcc/src/gcc-dist/gcc/passes.c:1120
#10 0x00d19254 in execute_ipa_pass_list (pass=0x1017fe04)
    at /vol/gcc/src/gcc-dist/gcc/passes.c:1743
#11 0x011d6504 in ipa_passes () at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1363
#12 0x011d6884 in cgraph_optimize ()
    at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1422
#13 0x011d5330 in cgraph_finalize_compilation_unit ()
    at /vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1090
#14 0x004c60a4 in c_write_global_declarations ()
    at /vol/gcc/src/gcc-dist/gcc/c-decl.c:9489
#15 0x00626034 in compile_file () at /vol/gcc/src/gcc-dist/gcc/toplev.c:1061
#16 0x0062ac60 in do_compile () at /vol/gcc/src/gcc-dist/gcc/toplev.c:2408
#17 0x0062ae8c in toplev_main (argc=25, argv=0x7ffbfeb4)
    at /vol/gcc/src/gcc-dist/gcc/toplev.c:2450
#18 0x00601160 in main (argc=25, argv=0x7ffbfeb4)
    at /vol/gcc/src/gcc-dist/gcc/main.c:35

So far, I couldn't reproduce this in an i386-pc-solaris2.10 -> mips-sgi-irix5.3
cross compiler.


-- 
           Summary: [4.5 regression] ICE building stage 1 libgcc on IRIX
                    5.3: SEGV in compare_access_positions
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix5.3
  GCC host triplet: mips-sgi-irix5.3
GCC target triplet: mips-sgi-irix5.3


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.5.0


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

------- Comment #1 from jamborm at gcc dot gnu dot org  2009-11-24 18:16 -------
Can you please add a check before the qsort call (tree-sra.c, line
1407) whether all pointers in the access_vec seem OK or whether it is
SRA that passes the invalid pointer to qsort?  Nothing fancy,
something as stupid as the loop below should do:

for (i =0; i < access_count; i++)
  gcc_assert (((unsigned) VEC_index (access_p, access_vec, i)) > 0x1000);

If it passes I can't see any other explanation but a bad qsort.  If it
doesn't we'll need to figure out how the bad pointers get there.

I don't have access to the architecture so I can't try it myself.


-- 


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE  2009-11-24 18:42 -------
Subject: Re:  [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in
compare_access_positions

> ------- Comment #1 from jamborm at gcc dot gnu dot org  2009-11-24 18:16 -------
> Can you please add a check before the qsort call (tree-sra.c, line
> 1407) whether all pointers in the access_vec seem OK or whether it is
> SRA that passes the invalid pointer to qsort?  Nothing fancy,
> something as stupid as the loop below should do:
>
> for (i =0; i < access_count; i++)
>   gcc_assert (((unsigned) VEC_index (access_p, access_vec, i)) > 0x1000);
>
> If it passes I can't see any other explanation but a bad qsort.  If it
> doesn't we'll need to figure out how the bad pointers get there.

It seems that the qsort is broken (although I haven't found any report
about qsort on IRIX 5.3 yet).  Anyway, I've added a slightly modified
qsort from glibc to libiberty (which won't work due to license
differences, I suppose, but maybe newlib is an option), which allowed
the bootstrap to continue.

I'll later check (either with the code above or with gdb watchpoints)
what is causing the corruption.

     Rainer


-- 


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc on IRIX 5.3: SEGV in compare_access_positions

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-11-27 11:27 -------
Thus invalid.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ebotcazou at gcc dot gnu dot org]

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-12-05 12:11 -------
Reopening, this happens on Solaris 8 as well:

This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) set args libgcc2.i -O
(gdb) run
Starting program: /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/gcc/cc1
libgcc2.i -O
 __muldi3
Analyzing compilation unit
Performing interprocedural optimizations
 <visibility> <*free_lang_data> <early_local_cleanups>
Program received signal SIGSEGV, Segmentation fault.
0x01258a98 in compare_access_positions (a=0x256ff7c, b=0x256ff84)
    at /nile.build/botcazou/gcc-head/src/gcc/tree-sra.c:1114
1114      if (f1->offset != f2->offset)
(gdb) bt
#0  0x01258a98 in compare_access_positions (a=0x256ff7c, b=0x256ff84)
    at /nile.build/botcazou/gcc-head/src/gcc/tree-sra.c:1114
#1  0xff2cb8ec in qsort () from /usr/lib/libc.so.1
#2  0x0125a15c in sort_and_splice_var_accesses (var=0xff145aa0)
    at /nile.build/botcazou/gcc-head/src/gcc/tree-sra.c:1426

It's a known issue on Solaris 8 when the comparer function returns inconsistent
results, i.e. when it fails to impose a total order on the array.  Given its
complexity, that isn't very suprising and should be fixed.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
  GCC build triplet|mips-sgi-irix5.3            |
   GCC host triplet|mips-sgi-irix5.3            |
 GCC target triplet|mips-sgi-irix5.3            |
            Summary|[4.5 regression] ICE        |[4.5 regression] ICE
                   |building stage 1 libgcc on  |building stage 1 libgcc:
                   |IRIX 5.3: SEGV in           |SEGV in
                   |compare_access_positions    |compare_access_positions


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ebotcazou at gcc dot gnu dot org]

------- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-12-05 12:12 -------
Reopened.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |major


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ebotcazou at gcc dot gnu dot org]

------- Comment #6 from ebotcazou at gcc dot gnu dot org  2009-12-05 12:39 -------
The problem is that the comparison of types is not anti-symmetrical:

(gdb) call compare_access_positions(&access_vec->base.vec[2],
&access_vec->base.vec[3])
$37 = 1
(gdb) call compare_access_positions(&access_vec->base.vec[3],
&access_vec->base.vec[2])
$38 = 1

(gdb) call compare_access_positions(&access_vec->base.vec[2],
&access_vec->base.vec[2])
$39 = 1

(gdb) p debug_tree(access_vec->base.vec[2]->type)
 <integer_type ff1059e0 SItype sizes-gimplified SI
    size <integer_cst ff008860 type <integer_type ff024060 bit_size_type>
constant 32>
    unit size <integer_cst ff008600 type <integer_type ff024000 unsigned int>
constant 4>
    align 32 symtab 0 alias set -1 canonical type ff0242a0 precision 32 min
<integer_cst ff008800 -2147483648> max <integer_cst ff008820 2147483647>>

(gdb) p debug_tree(access_vec->base.vec[3]->type)
 <integer_type ff1059e0 SItype sizes-gimplified SI
    size <integer_cst ff008860 type <integer_type ff024060 bit_size_type>
constant 32>
    unit size <integer_cst ff008600 type <integer_type ff024000 unsigned int>
constant 4>
    align 32 symtab 0 alias set -1 canonical type ff0242a0 precision 32 min
<integer_cst ff008800 -2147483648> max <integer_cst ff008820 2147483647>>


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-12-05 12:39:08
               date|                            |


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

------- Comment #7 from jamborm at gcc dot gnu dot org  2009-12-07 14:15 -------
(In reply to comment #6)
> The problem is that the comparison of types is not anti-symmetrical:

Looking at the code, I see that we don't stabilize the sort for
integers.  Can you please try the following (and untested) patch?
Thanks.

Index: mine/gcc/tree-sra.c
===================================================================
--- mine.orig/gcc/tree-sra.c
+++ mine/gcc/tree-sra.c
@@ -1134,10 +1134,17 @@ compare_access_positions (const void *a,
               && TREE_CODE (f2->type) != COMPLEX_TYPE
               && TREE_CODE (f2->type) != VECTOR_TYPE)
        return -1;
-      /* Put the integral type with the bigger precision first.  */
       else if (INTEGRAL_TYPE_P (f1->type)
               && INTEGRAL_TYPE_P (f2->type))
-       return TYPE_PRECISION (f1->type) > TYPE_PRECISION (f2->type) ? -1 : 1;
+       {
+         if (TYPE_PRECISION (f1->type) == TYPE_PRECISION (f2->type))
+           /* Stabilize the sort.  */
+           return TYPE_UID (f1->type) - TYPE_UID (f2->type);
+         else
+           /* Put the integral type with the bigger precision first.  */
+           return TYPE_PRECISION (f1->type) > TYPE_PRECISION (f2->type)
+             ? -1 : 1;
+       }
       /* Put any integral type with non-full precision last.  */
       else if (INTEGRAL_TYPE_P (f1->type)
               && (TREE_INT_CST_LOW (TYPE_SIZE (f1->type))


-- 


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

[Bug bootstrap/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2009-12-11 23:05 -------
I think

       /* Put the integral type with the bigger precision first.  */
       else if (INTEGRAL_TYPE_P (f1->type)
               && INTEGRAL_TYPE_P (f2->type)
               && TYPE_PRECISION (f1->type) != TYPE_PRECISION (f2->type))
         return TYPE_PRECISION (f1->type) > TYPE_PRECISION (f2->type) ? -1 : 1;

makes more sense.  But still if both types are equal we still do not stabilize
the sort.

Note

      /* Put any integral type with non-full precision last.  */
      else if (INTEGRAL_TYPE_P (f1->type)
               && (TREE_INT_CST_LOW (TYPE_SIZE (f1->type))
                   != TYPE_PRECISION (f1->type)))
        return 1;
      else if (INTEGRAL_TYPE_P (f2->type)
               && (TREE_INT_CST_LOW (TYPE_SIZE (f2->type))
                   != TYPE_PRECISION (f2->type)))
        return -1;

isn't stable either.  In fact - can't we have two exactly the same
accesses in the array?


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |tree-optimization
   GCC host triplet|                            |mips-sgi-irix5.3, sparc-sun-
                   |                            |solaris2.8
           Keywords|                            |build
           Priority|P3                          |P1


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

------- Comment #9 from jamborm at gcc dot gnu dot org  2009-12-16 20:58 -------
I'm now officially on vacation so I did not double check but...

(In reply to comment #8)
> I think
> 
>        /* Put the integral type with the bigger precision first.  */
>        else if (INTEGRAL_TYPE_P (f1->type)
>                && INTEGRAL_TYPE_P (f2->type)
>                && TYPE_PRECISION (f1->type) != TYPE_PRECISION (f2->type))
>          return TYPE_PRECISION (f1->type) > TYPE_PRECISION (f2->type) ? -1 : 1;
> 
> makes more sense.  But still if both types are equal we still do not stabilize
> the sort.
> 
> Note
> 
>       /* Put any integral type with non-full precision last.  */
>       else if (INTEGRAL_TYPE_P (f1->type)
>                && (TREE_INT_CST_LOW (TYPE_SIZE (f1->type))
>                    != TYPE_PRECISION (f1->type)))
>         return 1;
>       else if (INTEGRAL_TYPE_P (f2->type)
>                && (TREE_INT_CST_LOW (TYPE_SIZE (f2->type))
>                    != TYPE_PRECISION (f2->type)))
>         return -1;
> 
> isn't stable either.  In fact - can't we have two exactly the same
> accesses in the array?
> 

Of course we can have multiple accesses that are exactly the same.
The important thing is that we return zero for them.  In fact we
sometimes may not care which of two different accesses goes first and
we have to return zero for such pairs too.

As far as I can remember, we already do that for non-integer types
(because there is a subtraction of type UIDS just below the snippet
you pasted above and the branches you did paste do not trigger if both
types are integers because that is handled by a branch earlier which
causes the problems... and if only one of them is integer then we
return 1 for one ordering and -1 for the other, just as expected).
IIRC, we don't stabilize the sort only if both types are integers
because the type UID subtraction is missing and my patch ads that,
nothing more.

Internet access is expensive here so I types this in a bit of a ruch
but I hope it is understandable.


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

------- Comment #10 from jamborm at gcc dot gnu dot org  2009-12-21 15:35 -------
So given the above, I still think the patch from comment 7 will help.
Because I don't have any access to a non-Linux platform I cannot try
it myself and thus can only rely on others to test it for me.  I'll be
more than happy to cooperate further once someone does that.  Thanks.


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ebotcazou at gcc dot gnu dot org]

------- Comment #11 from ebotcazou at gcc dot gnu dot org  2009-12-29 15:56 -------
> So given the above, I still think the patch from comment 7 will help.
> Because I don't have any access to a non-Linux platform I cannot try
> it myself and thus can only rely on others to test it for me.  I'll be
> more than happy to cooperate further once someone does that.  Thanks.

Sorry for the delay.  Yes, the aforementioned patch is sufficient on Solaris 8.


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

------- Comment #12 from jamborm at gcc dot gnu dot org  2010-01-05 18:46 -------
I posted a slightly simpler patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00229.html


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-01-06 11:55 -------
Subject: Re:  [4.5 regression] ICE building stage 1 libgcc: SEGV in
compare_access_positions

> ------- Comment #12 from jamborm at gcc dot gnu dot org  2010-01-05 18:46 -------
> I posted a slightly simpler patch to the mailing list:
> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00229.html

I'm now running a C-only bootstrap with that patch on mips-sgi-irix5.3.
Your previous patch allowed a full bootstrap to finish without a
replacement qsort in libiberty.

        Rainer


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

------- Comment #14 from jamborm at gcc dot gnu dot org  2010-01-07 10:38 -------
Subject: Bug 42157

Author: jamborm
Date: Thu Jan  7 10:38:25 2010
New Revision: 155689

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155689
Log:
2010-01-07  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42157
        * tree-sra.c (compare_access_positions): Stabilize sort if both
        accesses have integer types, return zero immediately if they are the
        same.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-sra.c


-- 


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[jamborm at gcc dot gnu dot org]

------- Comment #15 from jamborm at gcc dot gnu dot org  2010-01-07 10:47 -------
The patch that I finally committed is also slightly different but should avoid
this problem too.


-- 

jamborm at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug tree-optimization/42157] [4.5 regression] ICE building stage 1 libgcc: SEGV in compare_access_positions

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #16 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-01-11 19:05 -------
Subject: Re:  [4.5 regression] ICE building stage 1 libgcc: SEGV in
compare_access_positions

> ------- Comment #13 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-01-06 11:55 -------
[...]
> I'm now running a C-only bootstrap with that patch on mips-sgi-irix5.3.
> Your previous patch allowed a full bootstrap to finish without a
> replacement qsort in libiberty.

That bootstrap finally completed, so the bug is definitely gone on IRIX
5.3, too.

Thanks.
        Rainer


-- 


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