A valgrind version of gcc trunk dated 20201206, with hash 8c23434fdadcf4ca, compiles testsuite file ./gcc.target/m68k/pr52573.c fine with compiler flag -O3 on x86_64. A week later, gcc trunk dated 20201211, with hash 97b56dece7413839, does this: ==11710== Conditional jump or move depends on uninitialised value(s) ==11710== at 0xE9DC54: vect_build_slp_instance(vec_info*, slp_instance_kind, vec<_stmt_vec_info*, va_heap, vl_p tr>&, _stmt_vec_info*, unsigned int, unsigned int*, hash_map<vec<gimple*, va_heap, vl_ptr>, _slp_tree*, simple_has hmap_traits<bst_traits, _slp_tree*> >*, _stmt_vec_info*) (tree-vect-slp.c:2396) The problem remains a week later in gcc trunk dated 20201218. I will have a look with git bisect.
Trying hash f6e8e2797ebae21e.
Seems good, so range reduces to f6e8e2797ebae21e..97b56dece7413839 Trying 4cf70c20cb10acd6
Seems ok, so range reduces to 4cf70c20cb10acd6..97b56dece7413839 Trying 7f359556a772e26e
Seems good, so range reduces to 7f359556a772e26e..97b56dece7413839 Trying 1423318fa7786493
Range so far seems to be 7f359556a772e26e..1423318fa7786493 Trying fa4a8b6463e0dbc2
So commit fc7b4248172561a9ee310e2d43d8a485a5c9e108 appears to be the culprit. May I ask Richard to confirm my git bisect analysis ?
Reduced test-case: $ cat m68.i struct { int : 12, : 11, k : 9; long l; } sH; int sH_3___trans_tmp_1, sH_3_i, sH_3_v; unsigned sH_3_s; void sH_3() { char *p = (char *)&sH; sH_3_i = 0; for (; sH_3_i < sizeof(sH); ++sH_3_i) { sH_3_s *= 515245; sH_3___trans_tmp_1 = sH_3_s % 2048; *p++ = sH_3___trans_tmp_1; } sH.k = sH_3_v; } $ ./xgcc -B. m68.i -c -O3 /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2486:16: runtime error: load of value 80, which is not a valid value for type 'bool' #0 0x2e89cbf in vect_build_slp_instance /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2486 #1 0x2e8b237 in vect_analyze_slp_instance /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2655 #2 0x2e8a0a2 in vect_build_slp_instance /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2524 #3 0x2e8b237 in vect_analyze_slp_instance /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2655 #4 0x2e8b4e5 in vect_analyze_slp(vec_info*, unsigned int) /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:2687 #5 0x2e9ac0c in vect_slp_analyze_bb_1 /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4507 #6 0x2e9b968 in vect_slp_region /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4619 #7 0x2e9d7d1 in vect_slp_bbs /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4767 #8 0x2e9e167 in vect_slp_function(function*) /home/marxin/Programming/gcc2/gcc/tree-vect-slp.c:4853 #9 0x2ee0503 in execute /home/marxin/Programming/gcc2/gcc/tree-vectorizer.c:1449 #10 0x200b8a1 in execute_one_pass(opt_pass*) /home/marxin/Programming/gcc2/gcc/passes.c:2567 #11 0x200c229 in execute_pass_list_1 /home/marxin/Programming/gcc2/gcc/passes.c:2656 #12 0x200c2de in execute_pass_list_1 /home/marxin/Programming/gcc2/gcc/passes.c:2657 #13 0x200c2de in execute_pass_list_1 /home/marxin/Programming/gcc2/gcc/passes.c:2657 #14 0x200c37c in execute_pass_list(function*, opt_pass*) /home/marxin/Programming/gcc2/gcc/passes.c:2667 #15 0x10e5be7 in cgraph_node::expand() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:1829 #16 0x10e753f in expand_all_functions /home/marxin/Programming/gcc2/gcc/cgraphunit.c:1997 #17 0x10e9669 in symbol_table::compile() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2361 #18 0x10e9ff6 in symbol_table::finalize_compilation_unit() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2542 #19 0x249ec80 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:482 #20 0x24a74c3 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2193 #21 0x24a7ac6 in toplev::main(int, char**) /home/marxin/Programming/gcc2/gcc/toplev.c:2332 #22 0x5146fda in main /home/marxin/Programming/gcc2/gcc/main.c:39 #23 0x7ffff6d2a151 in __libc_start_main (/lib64/libc.so.6+0x28151) #24 0xa0ba2d in _start (/dev/shm/objdir2/gcc/cc1+0xa0ba2d) And yes, it started with r11-5928-gfc7b4248172561a9.
Happens when: (gdb) p node $4 = (slp_tree) 0x0
Also from the testsuite, files ./gcc.c-torture/execute/20040709-1.c ./gcc.dg/torture/pr98235.c ./gcc.dg/tree-ssa/loop-34.c with -O3 show the same problem.
Reduced test case: typedef struct { short a; struct { unsigned short b; unsigned short c } d[] } e; enum { f, g, h, i }; e j; char k, l; e *m; void n(void) { int o; char *q, *r = 0, *s, *t, *p = &k; for (; *p; ++p) switch (o) { case f: o = s = p; case g: switch (*p) { case '@': t = p; o = h; } break; case h: q = p; case i: if (p == '#') r = p; } j.d[0].b = q - &k; j.d[0].c = r - q; if (s) { j.d[0].b = s - &k; j.d[0].c = t - s; } if (m) j.d[0].b = j.d[0].c = l; }
Mine. Looks like PR98270 but here we have more info.
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:0926259f9fc21a7f1e09f45f8aede156ef249585 commit r11-6437-g0926259f9fc21a7f1e09f45f8aede156ef249585 Author: Richard Biener <rguenther@suse.de> Date: Mon Jan 4 11:22:24 2021 +0100 tree-optimization/98393 - properly init matches when failing SLP This zeroes matches when failing SLP discovery because of the work limit. 2021-01-04 Richard Biener <rguenther@suse.de> PR tree-optimization/98393 * tree-vect-slp.c (vect_build_slp_tree): Properly zero matches when hitting the limit.
*** Bug 98270 has been marked as a duplicate of this bug. ***
Fixed.