Bug 215649 - clang version 3.9.1 assertion when compiling opencv >= 3.1
Summary: clang version 3.9.1 assertion when compiling opencv >= 3.1
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: Dimitry Andric
URL: https://llvm.org/bugs/show_bug.cgi?id...
Keywords:
: 216451 (view as bug list)
Depends on:
Blocks: 210505
  Show dependency treegraph
 
Reported: 2016-12-29 11:58 UTC by rozhuk.im
Modified: 2017-02-03 19:14 UTC (History)
4 users (show)

See Also:


Attachments
Preprocessed source(s) and associated run script(s) (748.99 KB, application/x-7z-compressed)
2016-12-29 11:58 UTC, rozhuk.im
no flags Details
TokenStream-cc4806.sh (4.41 KB, application/x-shellscript)
2017-01-26 18:41 UTC, Antoine Brodin
no flags Details
TokenStream-cc4806.cpp.gz (633.66 KB, application/gzip)
2017-01-26 18:43 UTC, Antoine Brodin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description rozhuk.im 2016-12-29 11:58:14 UTC
Created attachment 178373 [details]
Preprocessed source(s) and associated run script(s)

c++: error: unable to execute command: Segmentation fault (core dumped)
c++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM 3.9.1)
Target: x86_64-unknown-freebsd11.0
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
c++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/imgwarp-a19a25.cpp
c++: note: diagnostic msg: /tmp/imgwarp-a19a25.sh
c++: note: diagnostic msg: 

********************

(I try to build opencv 3.2)
Comment 1 rozhuk.im 2016-12-29 12:37:42 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
Comment 2 Dimitry Andric freebsd_committer 2016-12-30 22:31:20 UTC
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.
Comment 3 Dimitry Andric freebsd_committer 2017-01-25 12:01:53 UTC
*** Bug 216451 has been marked as a duplicate of this bug. ***
Comment 4 commit-hook freebsd_committer 2017-01-25 17:59:38 UTC
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
Comment 5 Antoine Brodin freebsd_committer 2017-01-26 18:39:09 UTC
This commit causes an assertion failure when building lang/spidermonkey24
Comment 6 Antoine Brodin freebsd_committer 2017-01-26 18:41:43 UTC
Created attachment 179336 [details]
TokenStream-cc4806.sh
Comment 7 Antoine Brodin freebsd_committer 2017-01-26 18:43:04 UTC
Created attachment 179337 [details]
TokenStream-cc4806.cpp.gz
Comment 8 commit-hook freebsd_committer 2017-01-26 20:19:04 UTC
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
Comment 9 commit-hook freebsd_committer 2017-01-26 20:40:27 UTC
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
Comment 10 otacilio.neto 2017-01-29 14:18:30 UTC
(In reply to commit-hook from comment #9)
After this commit I'm able to compile opencv 3.1
Comment 11 commit-hook freebsd_committer 2017-02-03 19:13:15 UTC
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