[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4

2018-09-13 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Richard Biener  ---
dup anyway

*** This bug has been marked as a duplicate of bug 87134 ***

[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4

2018-09-12 Thread rguenther at suse dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 12 Sep 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #3 from Jakub Jelinek  ---
> You mean like mtrace in glibc?
> Another option is try valgrind.

Yeah, it's said to not work on freebsd.  valgrind seems clean on
trunk x86_64-linux and I think that means everything is OK there...

I've just verified hash-map construction works as desired.

I wonder if side-stepping the small-object allocators by changing
the reserve_exact (2) to say reserve_exact (16) would change things...

That is, I'm absolutely not ruling out an allocator issue
(try tcmalloc?!)

[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4

2018-09-12 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
You mean like mtrace in glibc?
Another option is try valgrind.

[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4

2018-09-12 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271

--- Comment #2 from Richard Biener  ---
I wonder if there's a way to trace all malloc/realloc/free calls as well
(possibly simply via breakpoints and doing continue in their commands, logging
the result).

[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4

2018-09-10 Thread marxin at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-10
 CC||gerald at pfeifer dot com
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
One another back-trace for another reduced test-case:

$ (gdb) bt
#0  0x08519136 in memory_block_pool::allocate () at ../../gcc/memory-block.h:59
#1  0x08519663 in base_pool_allocator::allocate
(this=0xa3facc0 ) at ../../gcc/alloc-pool.h:373
#2  0x08659e58 in object_allocator::allocate (this=0xa3facc0
) at ../../gcc/alloc-pool.h:502
#3  0x08652bb9 in new_elt_loc_list (val=0x2addd00c, loc=0x2b2293c0) at
../../gcc/cselib.c:365
#4  0x08656052 in cselib_lookup_1 (x=0x2b2293c0, mode=E_SImode, create=1,
memmode=E_VOIDmode) at ../../gcc/cselib.c:2035
#5  0x08656489 in cselib_lookup (x=0x2b2293c0, mode=E_SImode, create=1,
memmode=E_VOIDmode) at ../../gcc/cselib.c:2141
#6  0x086573ab in cselib_record_sets (insn=0x2b1db8dc) at
../../gcc/cselib.c:2593
#7  0x08657db2 in cselib_process_insn (insn=0x2b1db8dc) at
../../gcc/cselib.c:2790
#8  0x09801c85 in local_cprop_pass () at ../../gcc/cprop.c:1293
#9  0x09802a48 in one_cprop_pass () at ../../gcc/cprop.c:1778
#10 0x09802f3e in execute_rtl_cprop () at ../../gcc/cprop.c:1932
#11 0x09803013 in (anonymous namespace)::pass_rtl_cprop::execute
(this=0x2ac5edc0) at ../../gcc/cprop.c:1970
#12 0x08ad607b in execute_one_pass (pass=0x2ac5edc0) at ../../gcc/passes.c:2446
#13 0x08ad63b4 in execute_pass_list_1 (pass=0x2ac5edc0) at
../../gcc/passes.c:2535
#14 0x08ad63e4 in execute_pass_list_1 (pass=0x2ac5ebc0) at
../../gcc/passes.c:2536
#15 0x08ad6430 in execute_pass_list (fn=0x2b10fc98, pass=0x2ac5b480) at
../../gcc/passes.c:2546
#16 0x08637115 in cgraph_node::expand (this=0x2b0ae898) at
../../gcc/cgraphunit.c:2121
#17 0x086376f0 in expand_all_functions () at ../../gcc/cgraphunit.c:2259
#18 0x08638189 in symbol_table::compile (this=0x2b0070c8) at
../../gcc/cgraphunit.c:2610
#19 0x0863858e in symbol_table::finalize_compilation_unit (this=0x2b0070c8) at
../../gcc/cgraphunit.c:2788
#20 0x08c33ea9 in compile_file () at ../../gcc/toplev.c:480
#21 0x08c36679 in do_compile () at ../../gcc/toplev.c:2170
#22 0x08c3694c in toplev::main (this=0xbfbfea1e, argc=13, argv=0xbfbfea84) at
../../gcc/toplev.c:2305
#23 0x099dabda in main (argc=13, argv=0xbfbfea84) at ../../gcc/main.c:39

$ (gdb) p instance.m_blocks 
$1 = (memory_block_pool::block_list *) 0x1

It looks some memory corruption is hapenning.
Gerald, would it be possible to build recebt GCC with -fsanitize=address on
the system?