This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/64231] New: SIGSEGV building glibc on aarch64-linux-gnu from r217852


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231

            Bug ID: 64231
           Summary: SIGSEGV building glibc on aarch64-linux-gnu from
                    r217852
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sandra at codesourcery dot com
                CC: belagod at gcc dot gnu.org
              Host: i686-pc-linux-gnu
            Target: aarch64-linux-gnu
             Build: i686-pc-linux-gnu

I have an aarch64-linux-gnu build tree with a glibc checkout from about a month
ago (revision 1400983e04d7b4b5a92db79ab27b0d0ec7d8bdef) that has started giving
a SEGV when building argp/argp-help.c.  I tracked it down to this GCC commit:


r217852 | belagod | 2014-11-20 05:58:23 -0800 (Thu, 20 Nov 2014) | 17 lines
2014-11-20  Tejas Belagod  <tejas.belagod@arm.com>

gcc/
    * config/aarch64/aarch64-protos.h (aarch64_classify_symbol):
    Fixup prototype.
    * config/aarch64/aarch64.c (aarch64_expand_mov_immediate,
    aarch64_cannot_force_const_mem, aarch64_classify_address,
    aarch64_classify_symbolic_expression): Fixup call to
    aarch64_classify_symbol.
    (aarch64_classify_symbol): Add range-checking for
    symbol + offset addressing for tiny and small models.

testsuite/
         * gcc.target/aarch64/symbol-range.c: New.
         * gcc.target/aarch64/symbol-range-tiny.c: New.

Here's the info from running the debugger on cc1.

Program received signal SIGSEGV, Segmentation fault.
plus_constant (mode=DImode, x=0xf78e1f30, c=144, inplace=<optimized out>, 
    inplace@entry=false)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120
120          if (memory_address_p (GET_MODE (tem), XEXP (tem, 0)))
(gdb) print debug_rtx(x)
(mem/u/c:DI (symbol_ref/u:DI ("*.LC39") [flags 0x2]) [4  S8 A64])
$6 = void
(gdb) print tem
$7 = (rtx) 0x0
(gdb) bt
#0  plus_constant (mode=DImode, x=0xf78e1f30, c=144, inplace=<optimized out>, 
    inplace@entry=false)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120
#1  0x082e2db3 in init_alias_analysis ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/alias.c:2966
#2  0x08b59682 in cse_main (nregs=<optimized out>, f=<optimized out>)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:6597
#3  0x08b5a5ec in rest_of_handle_cse2 ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7528
#4  (anonymous namespace)::pass_cse2::execute (this=0x92c99c8)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7581
#5  0x0868ca49 in execute_one_pass (pass=pass@entry=0x92c99c8)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2311
#6  0x0868cf16 in execute_pass_list_1 (pass=0x92c99c8)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2363
#7  0x0868cf26 in execute_pass_list_1 (pass=0x92c93c8, pass@entry=0x92c7288)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2364
#8  0x0868cf72 in execute_pass_list (fn=0xf7933dac, pass=0x92c7288)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2374
#9  0x08367a5d in cgraph_node::expand (this=this@entry=0xf794cd20)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:1773
#10 0x083692ff in expand_all_functions ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:1909
#11 symbol_table::compile (this=this@entry=0xf7c3b000)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:2263
#12 0x0836ae3d in symbol_table::finalize_compilation_unit (this=0xf7c3b000)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:2340
#13 0x081ec3a4 in c_write_global_declarations ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/c/c-decl.c:10777
#14 0x0874fdce in compile_file ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:584
#15 0x081d1823 in do_compile ()
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:2041
#16 toplev::main (this=this@entry=0xffffcfff, argc=argc@entry=103, 
    argv=argv@entry=0xffffd0b4)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:2138
#17 0x081d2175 in main (argc=103, argv=0xffffd0b4)
    at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/main.c:38

Hopefully this is enough info to track it down?  Seems clear that something in
the bad patch started causing force_const_mem to return NULL in this case and
the call site in plus_mem is not expecting that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]