Summary: | [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler | ||
---|---|---|---|
Product: | gcc | Reporter: | Arseny Solokha <asolokha> |
Component: | rtl-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | amonakov, andrewjenner, bill.schmidt, segher |
Priority: | P4 | Keywords: | ice-checking, ice-on-valid-code |
Version: | 8.0 | ||
Target Milestone: | 8.3 | ||
See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84345 | ||
Host: | Target: | powerpcspe-*-linux-gnu* | |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2018-01-10 00:00:00 | |
Bug Depends on: | |||
Bug Blocks: | 82407 |
Description
Arseny Solokha
2017-11-14 05:27:29 UTC
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 :-) |