Thank you for the report! > (1) FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect > "vectorized 2 loops" 1 > > before I saw > > [Book15] f90/bug% grep vectorized vect-pr43423.c.114t.vect > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: === > vect_mark_stmts_to_be_vectorized === > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: > loop vectorized > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: === > vect_mark_stmts_to_be_vectorized === > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: > loop vectorized > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: > vectorized 2 loops in function. > > after I see > > [Book15] f90/bug% grep vectorized vect-pr43423.c.115t.vect > > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:14:17: note: not > vectorized: not suitable for gather load _55 = a[_56]; > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:12:17: note: not > vectorized: not suitable for gather load _36 = a[_37]; > /opt/gcc/p_work/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c:6:6: note: > vectorized 0 loops in function.
We’ve already met with this problem. https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00118.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00155.html https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00173.html In our opinion, it requires help of the vectorizer people. Maybe it’ll disappear by itself, when the computation of types is finished. > (2) FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) > FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors) > > The backtrace is > > * thread #1: tid = 0x13bd91f, 0x00007fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x7fff5bc00ff8) > frame #0: 0x00007fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12: > -> 0x7fff8621aca0: pushq %rbx > 0x7fff8621aca1: pushq %rax > 0x7fff8621aca2: movl %edx, %r12d > 0x7fff8621aca5: movq %rsi, %r14 > (lldb) bt > * thread #1: tid = 0x13bd91f, 0x00007fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12, queue = > 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, > address=0x7fff5bc00ff8) > * frame #0: 0x00007fff8621aca0 > libsystem_malloc.dylib`tiny_malloc_from_free_list + 12 > frame #1: 0x00007fff8621b3c3 > libsystem_malloc.dylib`szone_malloc_should_clear + 320 > frame #2: 0x00007fff8621d868 libsystem_malloc.dylib`malloc_zone_malloc + > 71 > frame #3: 0x00007fff8621e27c libsystem_malloc.dylib`malloc + 42 > frame #4: 0x0000000141dbdc79 libgmp.10.dylib`__gmp_default_allocate + 9 > frame #5: 0x0000000141dd0148 libgmp.10.dylib`__gmpz_init + 24 > frame #6: 0x0000000141c180ef > libisl.10.dylib`isl_basic_map_normalize_constraints + 47 > frame #7: 0x0000000141c18f04 libisl.10.dylib`isl_basic_map_simplify + 68 > frame #8: 0x0000000141c2509b libisl.10.dylib`isl_basic_set_preimage + 619 > frame #9: 0x0000000141c4e146 > libisl.10.dylib`isl_basic_set_sample_with_cone + 150 > frame #10: 0x0000000141c4ea88 libisl.10.dylib`basic_set_sample + 744 > frame #11: 0x0000000141c4e849 libisl.10.dylib`basic_set_sample + 169 > frame #12: 0x0000000141c09978 libisl.10.dylib`isl_basic_map_is_empty + 136 > frame #13: 0x0000000141bb2870 libisl.10.dylib`domain_follows_at_depth + > 112 > frame #14: 0x0000000141c7cdba libisl.10.dylib`isl_tarjan_components + 154 > > getting to the ICE take ~19s compared to less than a second before r214069. This is a bug in ISL. They’ll fix it in a new version of ISL. https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk -- Cheers, Roman Gareev.
