[Bug tree-optimization/39978] New: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[Bug tree-optimization/39978] New: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[danglin at gcc dot gnu dot org]

if [ x"-fPIC" != x ]; then \
          /home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.5.0/arm-none-linux-gnueabi/bin/ -c
-DHAVE_CONFIG_H -g -O2 -I/home/dave/opt/gnu/include -I.
-I../../gcc/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic  -fPIC ../../gcc/libiberty/regex.c -o
pic/regex.o; \
        else true; fi
In file included from ../../gcc/libiberty/regex.c:638:
../../gcc/libiberty/regex.c: In function 'byte_re_compile_fastmap':
../../gcc/libiberty/regex.c:4541: internal compiler error: Segmentation fault

Performing interprocedural optimizations
 <visibility> <early_local_cleanups> {GC 5739k -> 2977k} <summary generate>
<cp> <inline> <static-var> <pure-const>Assembling functions:
 byte_compile_range byte_common_op_match_null_string_p
byte_alt_match_null_string_p byte_group_match_null_string_p xre_set_syntax
xre_set_registers xregfree xregerror byte_regex_compile {GC 5405k -> 3470k}
xre_comp xre_compile_pattern byte_re_compile_fastmap {GC 5325k ->
Program received signal SIGSEGV, Segmentation fault.
0x002c5398 in lookup_page_table_entry (p=0xafafafaf)
    at ../../gcc/gcc/ggc-page.c:588
588       return base[L1][L2];
(gdb) bt
#0  0x002c5398 in lookup_page_table_entry (p=0xafafafaf)
    at ../../gcc/gcc/ggc-page.c:588
#1  0x002c6294 in ggc_set_mark (p=0xafafafaf) at ../../gcc/gcc/ggc-page.c:1318
#2  0x0092fe80 in gt_ggc_mx_basic_block_def (x_p=0x404c3a78)
    at gtype-desc.c:859
#3  0x00930558 in gt_ggc_mx_gimple_statement_d (x_p=0x404c3a50)
    at gtype-desc.c:990
#4  0x00930228 in gt_ggc_mx_gimple_seq_node_d (x_p=0x4069c6b0)
    at gtype-desc.c:931
#5  0x00930310 in gt_ggc_mx_gimple_seq_d (x_p=0x40593770) at gtype-desc.c:947
#6  0x0092e094 in gt_ggc_mx_gimple_bb_info (x_p=0x40702ef8) at gtype-desc.c:269
#7  0x0092ffe0 in gt_ggc_mx_basic_block_def (x_p=0x40731740)
    at gtype-desc.c:879
#8  0x0092e89c in gt_ggc_mx_control_flow_graph (x_p=0x406b03b8)
    at gtype-desc.c:411
#9  0x0092f7b8 in gt_ggc_mx_function (x_p=0x4069ba50) at gtype-desc.c:732
#10 0x000dab18 in gt_ggc_mx_lang_tree_node (x_p=0x4021c2a0)
    at ./gt-c-decl.h:349
#11 0x000dad44 in gt_ggc_mx_lang_tree_node (x_p=0x402163f0)
    at ./gt-c-decl.h:376
#12 0x000dabbc in gt_ggc_mx_lang_tree_node (x_p=0x40216460)
    at ./gt-c-decl.h:356
#13 0x000dabbc in gt_ggc_mx_lang_tree_node (x_p=0x406b1150)
---Type <return> to continue, or q <return> to quit---
    at ./gt-c-decl.h:356
#14 0x000da918 in gt_ggc_mx_lang_tree_node (x_p=0x40772c80)
    at ./gt-c-decl.h:333
#15 0x0092ddc4 in gt_ggc_mx_cgraph_node (x_p=0x405ad800) at gtype-desc.c:229
#16 0x00934c34 in gt_ggc_m_P11cgraph_node4htab (x_p=0x401fae80)
    at gtype-desc.c:2147
#17 0x00827b88 in ggc_mark_roots () at ../../gcc/gcc/ggc-common.c:107
#18 0x002c7660 in ggc_collect () at ../../gcc/gcc/ggc-page.c:1941
#19 0x00b813ac in execute_todo (flags=2055) at ../../gcc/gcc/passes.c:1059
#20 0x00b81e74 in execute_one_pass (pass=0x2a6b690)
    at ../../gcc/gcc/passes.c:1314
#21 0x00b81fdc in execute_pass_list (pass=0x2a6b690)
    at ../../gcc/gcc/passes.c:1340
#22 0x00b82008 in execute_pass_list (pass=0x29b2db0)
    at ../../gcc/gcc/passes.c:1341
#23 0x01212bc0 in tree_rest_of_compilation (fndecl=0x403be000)
    at ../../gcc/gcc/tree-optimize.c:394
#24 0x01cdb6d0 in cgraph_expand_function (node=0x405ad400)
    at ../../gcc/gcc/cgraphunit.c:1051
#25 0x01cdb920 in cgraph_expand_all_functions ()
    at ../../gcc/gcc/cgraphunit.c:1110
#26 0x01cdc040 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1324
#27 0x000d896c in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8306

This is with

-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
Target: arm-none-linux-gnueabi
Configured with: ../gcc/configure --host=arm-none-linux-gnueabi
--target=arm-none-linux-gnueabi --build=arm-none-linux-gnueabi
--enable-languages=c,c++,fortran --enable-shared --enable-threads
--disable-multilib --disable-libmudflap --disable-libssp --enable-symvers=gnu
--enable-__cxa_atexit --disable-libstdcxx-pch
--prefix=/home/dave/opt/gnu/gcc/gcc-4.5.0 --with-gmp=/home/dave/opt/gnu
Thread model: posix
gcc version 4.5.0 20090429 (experimental) [trunk revision 146971] (GCC)


-- 
           Summary: [4.5 Regression] SEGV compiling libiberty/regex.c in
                    stage2
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: arm-none-linux-gnueabi
  GCC host triplet: arm-none-linux-gnueabi
GCC target triplet: arm-none-linux-gnueabi


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-30 17:55 -------
Interesting. I Knew about a PIC failure on arm but I the backtrace was
different, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 .


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
          Component|tree-optimization           |middle-end
           Keywords|                            |build, GC, ice-on-valid-code
   Target Milestone|---                         |4.5.0


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[ramana at gcc dot gnu dot org]

------- Comment #2 from ramana at gcc dot gnu dot org  2009-05-01 14:49 -------
 I don't see this with a bootstrap that I was doing with r147003. 

 /home/ramana/build-combined-arm-gcc-20090430/./gcc/xgcc -v
Using built-in specs.
Target: armv5tel-unknown-linux-gnueabi
Configured with: ../trunk/configure --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20090430 (experimental) [trunk revision 147003] (GCC)

though I do see a failure similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 while bootstrapping in
stage3.


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[rearnsha at gcc dot gnu dot org]

------- Comment #3 from rearnsha at gcc dot gnu dot org  2009-05-01 15:30 -------
This smells like a memory corruption problem in the compiler...


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-01 20:01 -------
Which pass? p *pass in frame 20 should tell you.


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[danglin at gcc dot gnu dot org]

------- Comment #5 from danglin at gcc dot gnu dot org  2009-05-01 20:32 -------
I'm not in my office where the box is, however, I believe the ICE occurs in
stage2.


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2009-05-04 13:48 -------
Subject: Re:  [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

> Which pass? p *pass in frame 20 should tell you.

(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x27bb734 "forwprop",
  gate = 0x152d6d4 <gate_forwprop>,
  execute = 0x152cc8c <tree_ssa_forward_propagate_single_use_vars>, sub = 0x0,
  next = 0x2a806c8, static_pass_number = 123, tv_id = TV_TREE_FORWPROP,
  properties_required = 40, properties_provided = 0, properties_destroyed = 0,
  todo_flags_start = 0, todo_flags_finish = 2055}

Dave


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[bonzini at gnu dot org]

------- Comment #7 from bonzini at gnu dot org  2009-05-06 15:35 -------
Is this reproducible with a crosscompiler and with --enable-checking=all,gcac? 
You can try valgrind too.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[danglin at gcc dot gnu dot org]

------- Comment #8 from danglin at gcc dot gnu dot org  2009-05-08 18:21 -------
Introduced in revision 146894:

2009-04-28  Andrew Pinski  <pinskia@gmail.com>

        PR target/39929
        * config/darwin.c (machopic_gen_offset): Check
        currently_expanding_to_rtl if current_ir_type returns IR_GIMPLE.
        * config/arm/arm.c (require_pic_register): Likewise.


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2009-05-08 19:35 -------
(In reply to comment #8)
> Introduced in revision 146894:

Interesting you don't hit the bug I described in PR 40031.


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca  2009-05-08 20:34 -------
Subject: Re:  [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

> Interesting you don't hit the bug I described in PR 40031.

I tested the following in the regression search:

146971 bad
146908 bad
146900 bad
146894 bad
146893 ok
146892 ok
146876 ok
146845 ok

The bug in PR 40031 was reported at 147121, so maybe things have
changed.

Dave


-- 


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[danglin at gcc dot gnu dot org]

------- Comment #11 from danglin at gcc dot gnu dot org  2009-05-12 13:06 -------
Build no longer ICEs.  I believe this PR was fixed by the
following change:

2009-05-10  Michael Matz  <matz@suse.de>

        PR target/40031
        * config/arm/arm.c (require_pic_register): Emit on entry edge,
        not at entry of function.


-- 

danglin at gcc dot gnu dot org changed:

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


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