gcc-8.0.0-alpha20171112 snapshot (r254666) for 32-bit BE powerpc targets ICEs on the following snippet w/ -misel -Ofast -fgraphite-identity -funroll-loops -fsched2-use-superblocks: int xw, mj; void km (void) { int r1 = 0; signed char *ny = (signed char *)&xw; if (xw != 0) for (;;) { for (xw = 1; xw < 3; ++xw) { for (*ny = 1; *ny < 2; ++*ny) ny = (signed char *)&mj; ++r1; if (r1 != 0) { w5: if (xw != 0) { for (*ny = 0; *ny < 1; ++*ny) ny = (signed char *)&r1; ++xw; } goto w5; } } } } % powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20171112 -misel -Ofast -fgraphite-identity -funroll-loops -fsched2-use-superblocks -c jyt0oer4.c jyt0oer4.c: In function 'km': jyt0oer4.c:31:1: error: qsort comparator non-negative on sorted output: 5 } ^ during RTL pass: sched2 jyt0oer4.c:31:1: internal compiler error: qsort checking failed 0x5c5263 qsort_chk_error /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/vec.c:222 0x150878a qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/vec.c:274 0x1401e7a ready_sort_real /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/haifa-sched.c:3087 0x140809f schedule_block(basic_block_def**, void*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/haifa-sched.c:6675 0x14a48f9 schedule_ebb(rtx_insn*, rtx_insn*, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-ebb.c:537 0x14a5106 schedule_ebbs() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-ebb.c:657 0xc115f4 rest_of_handle_sched2 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-rgn.c:3735 0xc115f4 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171112/work/gcc-8-20171112/gcc/sched-rgn.c:3873
Doesn't reproduce without graphite. Likely the problem is in rank_for_schedule.
With gcc-8.0.0-alpha20171217 snapshot it still reproduces for powerpc-e500v2-linux-gnuspe, but not for powerpc-e300c3-linux-gnu. Can it be a duplicate of PR83459?
> Can it be a duplicate of PR83459? No, this is a separate issue (the root cause here is different from the issue in sched-pressure ordering heuristic found by Jakub in the other bug).
Tried to re-create locally, I've gotten two ICE's using the provided testcode snippet, neither look quite like the originally reported issue. (thus I don't know if this is actually the same issue). Neither of these require the -fgraphite-identity option be specified. -m32 or -m64 doesn't seem to matter for me. Target: powerpc64-unknown-linux-gnu Configured with: /home/willschm/gcc/gcc-mainline-regtest_patches/configure --enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power7 --with-long-double-128 --prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches --disable-bootstrap --with-isl --with-graphite : (reconfigured) /home/willschm/gcc/gcc-mainline-regtest_patches/configure --enable-languages=c,c++ --with-cpu=power7 --with-long-double-128 --prefix=/home/willschm/gcc/install/gcc-mainline-regtest_patches --disable-bootstrap --with-isl --with-graphite # with -O2. > $GCC_INSTALL/bin/gcc ./pr82982.c -c -O2 -m32 during GIMPLE pass: store-merging ./pr82982.c: In function ‘km’: ./pr82982.c:4:1: internal compiler error: Segmentation fault km (void) ^~ 0x10f75447 crash_signal /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325 # with -O3. > $GCC_INSTALL/bin/gcc ./pr82982.c -c -O3 during IPA pass: cp ./pr82982.c:31:1: internal compiler error: Segmentation fault } ^ 0x10f75447 crash_signal /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/toplev.c:325 0x103de084 tree_check(tree_node*, char const*, int, char const*, tree_code) /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:3131 0x10da9e77 opts_for_fn /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/tree.h:5319 0x10dbe04b cgraph_node::optimize_for_size_p() /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/cgraph.h:3152 0x11e50afb ipcp_cloning_candidate_p /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:709 0x11e50ef3 initialize_node_lattices /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:1177 0x11e5df7b ipcp_propagate_stage /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:3284 0x11e5e317 ipcp_driver /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5026 0x11e5e3ff execute /home/willschm/gcc/gcc-mainline-regtest_patches/gcc/ipa-cp.c:5120
(In reply to Will Schmidt from comment #4) > Tried to re-create locally, I've gotten two ICE's using the provided > testcode snippet, neither look quite like the originally reported issue. You are right. I also cannot reproduce the original issue anymore w/ r257975.
(In reply to Will Schmidt from comment #4) > Tried to re-create locally, I've gotten two ICE's using the provided > testcode snippet, neither look quite like the originally reported issue. > (thus I don't know if this is actually the same issue). > > Neither of these require the -fgraphite-identity option be specified. -m32 > or -m64 doesn't seem to matter for me. ><...> (In reply to Arseny Solokha from comment #5) > (In reply to Will Schmidt from comment #4) > > Tried to re-create locally, I've gotten two ICE's using the provided > > testcode snippet, neither look quite like the originally reported issue. > > You are right. I also cannot reproduce the original issue anymore w/ r257975. Today I cannot get any ICE's out of this test. Wonder if things were fixed up in the mean-time, or if I tickled a config option and managed to hide the issue(s). Going to try a few more runs with older trees to see if I can verify things are fixed.
OK, the original issue still reproduces for the powerpc-e500v2-linux-gnuspe target as of r257975, so the change that affected this issue must have been local to the rs6000 backend.
(In reply to Will Schmidt from comment #6) > (In reply to Arseny Solokha from comment #5) > > (In reply to Will Schmidt from comment #4) > > > Tried to re-create locally, I've gotten two ICE's using the provided > > > testcode snippet, neither look quite like the originally reported issue. > > > > You are right. I also cannot reproduce the original issue anymore w/ r257975. > > Today I cannot get any ICE's out of this test. Wonder if things were fixed > up in the mean-time, or if I tickled a config option and managed to hide the > issue(s). Going to try a few more runs with older trees to see if I can > verify things are fixed. (In reply to Arseny Solokha from comment #7) > OK, the original issue still reproduces for the powerpc-e500v2-linux-gnuspe > target as of r257975, so the change that affected this issue must have been > local to the rs6000 backend. Ok. so at the moment I'm going to claim that I am unable to recreate the initially reported problem in my environments, which are 64-bit or 64/32 mixed. Nothing pure 32-bit here, nothing e300* or e500*, etc. The ICe's that I did see (comment #4) seem to be to be a separate issue. Those only occur in my sandbox/debug build of gcc, which has CFLAGS,CXXFLAGS,CFLAGS_FOR_BUILD, CFLAGS_FOR_TARGET, etc all set to "-O0 -g3 -fno-inline". I otherwise don't see any ICE with this test case.
SPE isn't primary/secondary, demoting.
GCC 8.1 has been released.
GCC 8.2 has been released.
I cannot reproduce it anymore for both powerpc-e300c3-linux-gnu and powerpc-e500v2-linux-gnuspe-gcc w/ gcc-9.0.0-alpha20180909 snapshot (rr264185).
Will, So I'll close this PR now. Please reopen if you can reproduce it again. Thanks everyone!
Erm, not Will. Everyone :-)