Bug 110443 - [14 Regression] ICE on a52dec-0.7.4: GIMPLE pass: vect SIGSEGV in vect_get_gather_scatter_ops()
Summary: [14 Regression] ICE on a52dec-0.7.4: GIMPLE pass: vect SIGSEGV in vect_get_ga...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 14.0
: P3 normal
Target Milestone: 14.0
Assignee: Richard Biener
URL:
Keywords: ice-on-valid-code
: 110440 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-06-27 19:46 UTC by Sergei Trofimovich
Modified: 2023-06-30 06:18 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2023-06-28 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Trofimovich 2023-06-27 19:46:46 UTC
Noticerd ICE on a52dec-0.7.4 against gcc r14-2134-g231f6b56c77c50. Extracted minimal example is:

Extracted reproducer:

// $ cat bug.c.c
typedef struct {
  float real;
  float imag;
} complex_t;
char fftorder[] = {};
float *a52_imdct_256_data;
int a52_imdct_256_i, a52_imdct_256_k;
float a52_imdct_256_b_r;
void a52_imdct_256() {
  complex_t buf1[64];
  a52_imdct_256_i = 0;
  for (; a52_imdct_256_i < 64; a52_imdct_256_i++) {
    a52_imdct_256_k = fftorder[a52_imdct_256_i];
    buf1[a52_imdct_256_i].real = buf1[a52_imdct_256_i].imag =
        a52_imdct_256_data[a52_imdct_256_k];
  }
  a52_imdct_256_b_r = buf1[0].real * buf1[0].imag;
}

$ gcc -O2 -c bug.c.c -o bug.o
during GIMPLE pass: vect
bug.c.c: In function 'a52_imdct_256':
bug.c.c:9:6: internal compiler error: Segmentation fault
    9 | void a52_imdct_256() {
      |      ^~~~~~~~~~~~~
0x1bc5d04 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t)
        ???:0
0x1bc6277 internal_error(char const*, ...)
        ???:0
0xcca64f crash_signal(int)
        ???:0
0x1a84a18 vect_get_gather_scatter_ops(_loop_vec_info*, loop*, _stmt_vec_info*, _slp_tree*, gather_scatter_info*, tree_node**, vec<tree_node*, va_heap, vl_ptr>*)
        ???:0
0x1a92fb2 vectorizable_load(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*, gimple**, _slp_tree*, vec<stmt_info_for_cost, va_heap, vl_ptr>*)
        ???:0
0x1aa01d8 vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
        ???:0
0xf2ab57 vect_schedule_slp_node(vec_info*, _slp_tree*, _slp_instance*)
        ???:0
0xf3abcb vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*, hash_map<_slp_tree*, slp_scc_info, simple_hashmap_traits<default_hash_traits<_slp_tree*>, slp_scc_info> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&)
        ???:0
0xf3a812 vect_schedule_scc(vec_info*, _slp_tree*, _slp_instance*, hash_map<_slp_tree*, slp_scc_info, simple_hashmap_traits<default_hash_traits<_slp_tree*>, slp_scc_info> >&, int&, vec<_slp_tree*, va_heap, vl_ptr>&)
        ???:0
0xf3b166 vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr> const&)
        ???:0
0xf0f23b vect_transform_loop(_loop_vec_info*, gimple*)
        ???:0
0xf4833b vect_transform_loops(hash_table<simduid_to_vf, false, xcallocator>*&, loop*, gimple*, function*)
        ???:0
0xf489db try_vectorize_loop(hash_table<simduid_to_vf, false, xcallocator>*&, unsigned int*, loop*, function*)
        ???:0
0xf48f34 (anonymous namespace)::pass_vectorize::execute(function*)
        ???:0

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<<NIX>>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<<NIX>>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 99999999 (experimental) (GCC)
Comment 1 Andrew Pinski 2023-06-27 19:50:09 UTC
This is related to PR 110440 but the reduced testcases look almost the same but the ICE is different in both cases.
Comment 2 Sergei Trofimovich 2023-06-27 22:20:10 UTC
I wonder if it's a r14-2117-gdd86a5a69cbda4 "tree-optimization/96208 - SLP of non-grouped loads".
Comment 3 Sergei Trofimovich 2023-06-27 22:52:30 UTC
(In reply to Sergei Trofimovich from comment #2)
> I wonder if it's a r14-2117-gdd86a5a69cbda4 "tree-optimization/96208 - SLP
> of non-grouped loads".

Reverting r14-2117-gdd86a5a69cbda4 fixes a52dec-0.7.4 for me.
Comment 4 Richard Biener 2023-06-28 07:56:37 UTC
I will have a look.
Comment 5 GCC Commits 2023-06-28 09:13:04 UTC
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:51c8cbc6bba387f953d9be48c4a4c8b657dd54a5

commit r14-2156-g51c8cbc6bba387f953d9be48c4a4c8b657dd54a5
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Jun 28 10:16:57 2023 +0200

    tree-optimization/110443 - prevent SLP splat of gathers
    
    The following prevents non-grouped load SLP in case the element
    to splat is from a gather operation.  While it should be possible
    to support this it is not similar to the single element interleaving
    case I was trying to mimic here.
    
            PR tree-optimization/110443
            * tree-vect-slp.cc (vect_build_slp_tree_1): Reject non-grouped
            gather loads.
    
            * gcc.dg/torture/pr110443.c: New testcase.
Comment 6 Richard Biener 2023-06-28 09:13:14 UTC
Fixed.
Comment 7 Richard Biener 2023-06-28 09:13:29 UTC
*** Bug 110440 has been marked as a duplicate of this bug. ***
Comment 8 Sergei Trofimovich 2023-06-28 13:55:22 UTC
I confirm a52dec-0.7.4 is fixed as well now. Thank you!
Comment 9 seurer 2023-06-29 23:33:43 UTC
I am still seeing this failure with r14-2201-g94c71750cdd742 

This is compiling one of the spec test cases on a powerpc BE machine.

/home/seurer/gcc/git/install/gcc-test/bin/gfortran -c -o module_bc_time_utilities.fppized.o -I. -I./netcdf/include -m64 -O3 -mcpu=power7 -fpeel-loops -funroll-loops -ffast-math -mpopcntd -mrecip=rsqrt -fvect-cost-model -std=legacy module_bc_time_utilities.fppized.f90
0x10cceb2b crash_signal
	/home/seurer/gcc/git/gcc-test/gcc/toplev.cc:314
0x11c8596c vect_supportable_dr_alignment(vec_info*, dr_vec_info*, tree_node*, int)
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-data-refs.cc:6817
0x11ca16c3 get_group_load_store_type
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:2445
0x11ca16c3 get_load_store_type
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:2564
0x11cb498f vectorizable_load
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:9547
0x11cc7e5b vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec<stmt_info_for_cost, va_heap, vl_ptr>*)
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.cc:11910
0x110c1833 vect_slp_analyze_node_operations_1
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:5993
0x110c1833 vect_slp_analyze_node_operations
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6191
0x110c1757 vect_slp_analyze_node_operations
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c1757 vect_slp_analyze_node_operations
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c1757 vect_slp_analyze_node_operations
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c1757 vect_slp_analyze_node_operations
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6170
0x110c3b63 vect_slp_analyze_operations(vec_info*)
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-slp.cc:6431
0x1108a10b vect_analyze_loop_2
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:2782
0x1108c73b vect_analyze_loop_1
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3303
0x1108d093 vect_analyze_loop(loop*, vec_info_shared*)
	/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.cc:3457
0x110e2507 try_vectorize_loop_1
	/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1064
0x110e2507 try_vectorize_loop
	/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1180
0x110e2d43 execute
	/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.cc:1296

I also traced this back to r14-2117-gdd86a5a69cbda4
Comment 10 Richard Biener 2023-06-30 06:18:18 UTC
That seems to be a different backtrace and it doesn't have a testcase.  Can you please open a new bugreport and attach a testcase?