Bug 98264 - [11 Regression] ice during linear_loads_p since r11-5969-g3ed472af6bc9f83b
Summary: [11 Regression] ice during linear_loads_p since r11-5969-g3ed472af6bc9f83b
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 11.0
: P1 normal
Target Milestone: 11.0
Assignee: Tamar Christina
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: spec
  Show dependency treegraph
 
Reported: 2020-12-13 21:38 UTC by David Binderman
Modified: 2020-12-14 15:22 UTC (History)
3 users (show)

See Also:
Host:
Target: x86_64
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-12-14 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Binderman 2020-12-13 21:38:49 UTC
For C testsuite file ./gcc.target/i386/avx-vaddsubpd-1.c

$ /home/dcb/gcc/results.20201213/bin/gcc -c -march=bdver2 -O3 ./gcc.target/i386/avx-vaddsubpd-1.c
during GIMPLE pass: slp
In file included from ./gcc.target/i386/sse3-addsubpd.c:13,
                 from ./gcc.target/i386/avx-vaddsubpd-1.c:8:
./gcc.target/i386/avx-check.h: In function ‘do_test’:
./gcc.target/i386/avx-check.h:10:1: internal compiler error: Segmentation fault
   10 | do_test (void)
      | ^~~~~~~
0xcf2e49 crash_signal(int)
	../../trunk.git/gcc/toplev.c:327
0xfd3f47 vec<unsigned int, va_heap, vl_embed>::operator[](unsigned int)
	../../trunk.git/gcc/vec.h:890
0xfd3f47 vec<unsigned int, va_heap, vl_ptr>::operator[](unsigned int)
	../../trunk.git/gcc/vec.h:1461
0xfd3f47 linear_loads_p(hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> >, simple_hashmap_traits<default_hash_traits<_slp_tree*>, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> > > >*, _slp_tree*)

The gcc compiler seems fine at hash 97b56dece7413839
and broken at 3cc4e183f12e9626
Comment 1 David Binderman 2020-12-13 21:43:34 UTC
Trying a git bisect now. First step hash 54f75d8fb3f54541e37432329581a362e6aab94e
Comment 2 David Binderman 2020-12-13 21:56:08 UTC
Seems ok. Try 1751a78ecafb1d16d4a843dd22e739b8fd1cfede
Comment 3 David Binderman 2020-12-13 22:07:31 UTC
Seems ok. Trying 10bbba9145700e2c.
Comment 4 David Binderman 2020-12-13 22:18:43 UTC
10bbba9145700e2c won't build ;-<

git bisect skip says 3ed472af6bc9f83b7a8ac553b282f659a0bf53f7. Try that.
Comment 5 David Binderman 2020-12-13 22:25:52 UTC
Looks bad. Trying 501f470267445e03
Comment 6 David Binderman 2020-12-13 22:36:01 UTC
Looks good. So range is [501f470267445e03..3ed472af6bc9f83b].
Both of those have author  Tamar Christina <tamar.christina@arm.com>
I am no expert at git bisect, so over to Tamar for further advice.

I used a configure line of

./trunk.git/configure --prefix=/home/dcb/gcc/results.$HASH \
	--disable-bootstrap \
	--disable-multilib \
	--disable-werror \
	--with-pkgversion=$HASH \
	--enable-checking=release \
	--enable-languages=c

with

sed 's/-O2/-O0/' < Makefile > Makefile.tmp
diff Makefile Makefile.tmp
mv Makefile.tmp Makefile

Any news of anything faster would be appreciated.
Comment 7 Tamar Christina 2020-12-14 08:45:15 UTC
confirmed, testing patch.

Curiously this tests runs with `-O2 -mavx -mfpmath=sse` for me locally which passes but I can reproduce it using the reported flags.

> Any news of anything faster would be appreciated.

You don't have to rebuild the whole thing at every step just the C compiler since this is a C test.

So once you build it once you can go into the build dir (since you're doing a non-bootstrap build) and do `make cc1 -C gcc -j <num>` . Which should take just seconds.

If you're doing a bootstrapped build you should just build the last stage.

You can then run the testcase using the `xgcc` command you see in the log (you don't need the install).
Comment 8 Martin Liška 2020-12-14 09:14:53 UTC
Started with r11-5969-g3ed472af6bc9f83b, it fails due to a Invalid read:

$ valgrind --trace-children=yes gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-vaddsubpd-1.c -c -c -march=bdver2 -O3 -c
...
==15595== Invalid read of size 4
==15595==    at 0x109B3DB: operator[] (vec.h:890)
==15595==    by 0x109B3DB: operator[] (vec.h:1461)
==15595==    by 0x109B3DB: linear_loads_p(hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> >, simple_hashmap_traits<default_hash_traits<_slp_tree*>, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> > > >*, _slp_tree*) (tree-vect-slp-patterns.c:255)
==15595==    by 0x109B63A: complex_add_pattern::matches(_complex_operation, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> >, simple_hashmap_traits<default_hash_traits<_slp_tree*>, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> > > >*, vec<_slp_tree*, va_heap, vl_ptr>*) (tree-vect-slp-patterns.c:678)
==15595==    by 0x109B6C9: complex_add_pattern::recognize(hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> >, simple_hashmap_traits<default_hash_traits<_slp_tree*>, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> > > >*, _slp_tree**) (tree-vect-slp-patterns.c:697)
==15595==    by 0x108FEEC: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> >, simple_hashmap_traits<default_hash_traits<_slp_tree*>, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> > > >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.c:2257)
==15595==    by 0x108FEB1: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> >, simple_hashmap_traits<default_hash_traits<_slp_tree*>, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> > > >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.c:2252)
==15595==    by 0x108FEB1: vect_match_slp_patterns_2(_slp_tree**, vec_info*, hash_map<_slp_tree*, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> >, simple_hashmap_traits<default_hash_traits<_slp_tree*>, std::pair<_complex_perm_kinds, vec<unsigned int, va_heap, vl_ptr> > > >*, hash_set<_slp_tree*, false, default_hash_traits<_slp_tree*> >*) (tree-vect-slp.c:2252)
==15595==    by 0x1090277: vect_match_slp_patterns (tree-vect-slp.c:2290)
==15595==    by 0x1090277: vect_analyze_slp(vec_info*, unsigned int) (tree-vect-slp.c:2743)
==15595==    by 0x10974B2: vect_slp_analyze_bb_1 (tree-vect-slp.c:4507)
==15595==    by 0x10974B2: vect_slp_region (tree-vect-slp.c:4619)
==15595==    by 0x10974B2: vect_slp_bbs(vec<basic_block_def*, va_heap, vl_ptr>) (tree-vect-slp.c:4767)
==15595==    by 0x1098F54: vect_slp_function(function*) (tree-vect-slp.c:4853)
==15595==    by 0x109C362: (anonymous namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.c:1449)
==15595==    by 0xD1F357: execute_one_pass(opt_pass*) (passes.c:2567)
==15595==    by 0xD1FCFF: execute_pass_list_1(opt_pass*) (passes.c:2656)
==15595==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==15595== 
during GIMPLE pass: slp
In file included from /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/sse3-addsubpd.c:13,
                 from /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-vaddsubpd-1.c:8:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-check.h: In function ‘do_test’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/avx-check.h:10:1: internal compiler error: Segmentation fault
   10 | do_test (void)
      | ^~~~~~~
0x4fff151 __libc_start_main
	???:0
Comment 9 Martin Liška 2020-12-14 09:24:52 UTC
Apparently, it's blocking couple of SPEC benchmarks:

-Ofast -march=znver2 -g -flto=128:

warning: 416.gamess(peak; CE) benchmark build failed!
warning: 465.tonto(peak; CE) benchmark build failed!
warning: 483.xalancbmk(peak; CE) benchmark build failed!
Comment 10 GCC Commits 2020-12-14 15:21:30 UTC
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:159b0bd9ce263dfb791eff5133b0ca0207201c84

commit r11-5993-g159b0bd9ce263dfb791eff5133b0ca0207201c84
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Mon Dec 14 15:20:05 2020 +0000

    middle-end: Exclude TOP permute from blend considerations
    
    Similarly to UNKNOWN permutes, TOP needs to be excluded from being considered
    for blends because it produces no permute to check.
    
    gcc/ChangeLog:
    
            PR middle-end/98264
            * tree-vect-slp-patterns.c (linear_loads_p): Exclude TOP permute.
    
    gcc/testsuite/ChangeLog:
    
            PR middle-end/98264
            * gcc.target/i386/pr98264.c: New test.
Comment 11 Tamar Christina 2020-12-14 15:22:55 UTC
This should be fixed now.