Bug 215649
| Summary: | clang version 3.9.1 assertion when compiling opencv >= 3.1 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Ivan Rozhuk <rozhuk.im> | ||||||||
| Component: | bin | Assignee: | Dimitry Andric <dim> | ||||||||
| Status: | Closed FIXED | ||||||||||
| Severity: | Affects Some People | CC: | dim, emaste, otacilio.neto, rozhuk.im | ||||||||
| Priority: | --- | ||||||||||
| Version: | 11.0-STABLE | ||||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| URL: | https://llvm.org/bugs/show_bug.cgi?id=30775 | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 210505 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Ivan Rozhuk
2016-12-29 11:58:14 UTC
and clang from ports: Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE && "NodeToMatch was removed partway through selection"), function SelectCodeCommon, file /tmp/ports/usr/ports/devel/llvm39/work/llvm-3.9.1.src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 3387. clang-3.9: error: unable to execute command: Abort trap (core dumped) clang-3.9: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.9.1 (tags/RELEASE_391/final) Target: x86_64-unknown-freebsd11.0 Thread model: posix InstalledDir: /usr/local/llvm39/bin clang-3.9: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-3.9: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3.9: note: diagnostic msg: /tmp/imgwarp-a675da.cpp clang-3.9: note: diagnostic msg: /tmp/imgwarp-a675da.sh clang-3.9: note: diagnostic msg: ******************** *** [modules/imgproc/CMakeFiles/opencv_imgproc.dir/src/imgwarp.cpp.o] Error code 254 clang 3.7 and 3.8 - OK This is most likely upstream LLVM PR 30775: https://llvm.org/bugs/show_bug.cgi?id=30775 Unfortunately the preprocessed code doesn't compile with llvm trunk, so I'm reducing the test case locally, to see whether it still reproduces. *** Bug 216451 has been marked as a duplicate of this bug. *** A commit references this bug: Author: dim Date: Wed Jan 25 17:59:22 UTC 2017 New revision: 312765 URL: https://svnweb.freebsd.org/changeset/base/312765 Log: Pull in r276136 from upstream llvm trunk (by Wei Mi): Use ValueOffsetPair to enhance value reuse during SCEV expansion. In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult. A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding. In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b. Differential Revision: https://reviews.llvm.org/D21313 This should fix assertion failures when building OpenCV >= 3.1. PR: 215649 MFC after: 3 days Changes: head/contrib/llvm/include/llvm/Analysis/ScalarEvolution.h head/contrib/llvm/include/llvm/Analysis/ScalarEvolutionExpander.h head/contrib/llvm/lib/Analysis/ScalarEvolution.cpp head/contrib/llvm/lib/Analysis/ScalarEvolutionExpander.cpp This commit causes an assertion failure when building lang/spidermonkey24 Created attachment 179336 [details]
TokenStream-cc4806.sh
Created attachment 179337 [details]
TokenStream-cc4806.cpp.gz
A commit references this bug: Author: dim Date: Thu Jan 26 20:18:28 UTC 2017 New revision: 312831 URL: https://svnweb.freebsd.org/changeset/base/312831 Log: Revert r312765 for now, since it causes assertions when building lang/spidermonkey24. Reported by: antoine PR: 215649 Changes: head/contrib/llvm/include/llvm/Analysis/ScalarEvolution.h head/contrib/llvm/include/llvm/Analysis/ScalarEvolutionExpander.h head/contrib/llvm/lib/Analysis/ScalarEvolution.cpp head/contrib/llvm/lib/Analysis/ScalarEvolutionExpander.cpp A commit references this bug: Author: dim Date: Thu Jan 26 20:39:43 UTC 2017 New revision: 312832 URL: https://svnweb.freebsd.org/changeset/base/312832 Log: Pull in r278160 from upstream llvm trunk (by Wei Mi): Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion". The fix for PR28705 will be committed consecutively. In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult. A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding. In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b. Differential Revision: https://reviews.llvm.org/D21313 Pull in r278161 from upstream llvm trunk (by Wei Mi): Fix the runtime error caused by "Use ValueOffsetPair to enhance value reuse during SCEV expansion". The patch is to fix the bug in PR28705. It was caused by setting wrong return value for SCEVExpander::findExistingExpansion. The return values of findExistingExpansion have different meanings when the function is used in different ways so it is easy to make mistake. The fix creates two new interfaces to replace SCEVExpander::findExistingExpansion, and specifies where each interface is expected to be used. Differential Revision: https://reviews.llvm.org/D22942 Pull in r281439 from upstream llvm trunk (by Wei Mi): Create a getelementptr instead of sub expr for ValueOffsetPair if the value is a pointer. This patch is to fix PR30213. When expanding an expr based on ValueOffsetPair, if the value is of pointer type, we can only create a getelementptr instead of sub expr. Differential Revision: https://reviews.llvm.org/D24088 This should fix assertion failures when building OpenCV >= 3.1, and also allow building lang/spidermonkey24 without any further assertions. PR: 215649 MFC after: 1 week Changes: head/contrib/llvm/include/llvm/Analysis/ScalarEvolution.h head/contrib/llvm/include/llvm/Analysis/ScalarEvolutionExpander.h head/contrib/llvm/lib/Analysis/ScalarEvolution.cpp head/contrib/llvm/lib/Analysis/ScalarEvolutionExpander.cpp head/contrib/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp (In reply to commit-hook from comment #9) After this commit I'm able to compile opencv 3.1 A commit references this bug: Author: dim Date: Fri Feb 3 19:12:55 UTC 2017 New revision: 313170 URL: https://svnweb.freebsd.org/changeset/base/313170 Log: MFC r312832: Pull in r278160 from upstream llvm trunk (by Wei Mi): Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion". The fix for PR28705 will be committed consecutively. In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult. A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding. In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b. Differential Revision: https://reviews.llvm.org/D21313 Pull in r278161 from upstream llvm trunk (by Wei Mi): Fix the runtime error caused by "Use ValueOffsetPair to enhance value reuse during SCEV expansion". The patch is to fix the bug in PR28705. It was caused by setting wrong return value for SCEVExpander::findExistingExpansion. The return values of findExistingExpansion have different meanings when the function is used in different ways so it is easy to make mistake. The fix creates two new interfaces to replace SCEVExpander::findExistingExpansion, and specifies where each interface is expected to be used. Differential Revision: https://reviews.llvm.org/D22942 Pull in r281439 from upstream llvm trunk (by Wei Mi): Create a getelementptr instead of sub expr for ValueOffsetPair if the value is a pointer. This patch is to fix PR30213. When expanding an expr based on ValueOffsetPair, if the value is of pointer type, we can only create a getelementptr instead of sub expr. Differential Revision: https://reviews.llvm.org/D24088 This should fix assertion failures when building OpenCV >= 3.1, and also allow building lang/spidermonkey24 without any further assertions. PR: 215649 Changes: _U stable/11/ stable/11/contrib/llvm/include/llvm/Analysis/ScalarEvolution.h stable/11/contrib/llvm/include/llvm/Analysis/ScalarEvolutionExpander.h stable/11/contrib/llvm/lib/Analysis/ScalarEvolution.cpp stable/11/contrib/llvm/lib/Analysis/ScalarEvolutionExpander.cpp stable/11/contrib/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp |
