Bug 39978 - [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
Summary: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.5.0
: P1 normal
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords: build, GC, ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2009-04-30 17:19 UTC by John David Anglin
Modified: 2009-05-12 13:06 UTC (History)
3 users (show)

See Also:
Host: arm-none-linux-gnueabi
Target: arm-none-linux-gnueabi
Build: arm-none-linux-gnueabi
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2009-04-30 17:19:27 UTC
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)
Comment 1 Andrew Pinski 2009-04-30 17:55:02 UTC
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 .
Comment 2 Ramana Radhakrishnan 2009-05-01 14:49:41 UTC
 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.





Comment 3 Richard Earnshaw 2009-05-01 15:30:24 UTC
This smells like a memory corruption problem in the compiler...
Comment 4 Richard Biener 2009-05-01 20:01:48 UTC
Which pass? p *pass in frame 20 should tell you.
Comment 5 John David Anglin 2009-05-01 20:32:10 UTC
I'm not in my office where the box is, however, I believe the ICE occurs in
stage2.
Comment 6 dave 2009-05-04 13:48:13 UTC
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
Comment 7 Paolo Bonzini 2009-05-06 15:35:55 UTC
Is this reproducible with a crosscompiler and with --enable-checking=all,gcac?  You can try valgrind too.
Comment 8 John David Anglin 2009-05-08 18:21:05 UTC
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.
Comment 9 Andrew Pinski 2009-05-08 19:35:41 UTC
(In reply to comment #8)
> Introduced in revision 146894:

Interesting you don't hit the bug I described in PR 40031.
Comment 10 dave 2009-05-08 20:34:28 UTC
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
Comment 11 John David Anglin 2009-05-12 13:06:32 UTC
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.