[llvm-bugs] [Bug 34832] New: Commits rL314375 caused intermittent build failures for SPEC2006 benchmarks

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=34832

            Bug ID: 34832
           Summary: Commits rL314375 caused intermittent build failures
                    for SPEC2006 benchmarks
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: lei at ca.ibm.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 19229
  --> https://bugs.llvm.org/attachment.cgi?id=19229&action=edit
Crash backtrace

The following spec2006 benchmarks fails to build intermittently:
450.soplex(base; CE), 458.sjeng(base; CE), 447.dealII(base; CE),
453.povray(base; CE)

Intermittent build failure only happens if compiling with the new pass manager. 
This is reproducible on PPC and MacOSX.

To reproduce, run repeat.sh

$ cat a.c
typedef struct node {
  char value;
  int proof;
  int disproof;
  struct node *parent
} node_t;
node_t *a;
proofnumbercheck() {
  node_t *b;
  3;
  while (a->proof && a->disproof)
    ;
  while (b != a)
    b = b->parent;
}

$cat repeat.sh
#! /bin/bash

RUN_NUM=2000
I=0
while [[ $I -lt $RUN_NUM ]]
do
  clang -O3 -fexperimental-new-pass-manager -c a.c > out 2>&1
  grep "Stack dump:" out > /dev/null
  rc=$?
  if [[ $rc == 0 ]]
  then
    echo "Run $I failed!!"
    cat out
    exit 0
  fi
  ((I += 1))
done

echo "All $RUN_NM runs passed!"
exit 1

Output:
------------------------------------------------
a.c:5:22: warning: expected ';' at end of declaration list
  struct node *parent
                     ^
                     ;
a.c:8:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
proofnumbercheck() {
^
a.c:10:3: warning: expression result unused [-Wunused-value]
  3;
  ^
a.c:15:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
0  clang-6.0                0x000000010bebab68
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  clang-6.0                0x000000010bebb226 SignalHandler(int) + 470
2  libsystem_platform.dylib 0x00007fffb70a3b3a _sigtramp + 26
3  libsystem_platform.dylib 0x00007fce80415070 _sigtramp + 3375830352
4  clang-6.0                0x000000010b9cb9f9 llvm::Value::getName() const +
25
5  clang-6.0                0x000000010b4919f5
llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop,
llvm::LoopStandardAnalysisResults&>,
llvm::Function>::Result::invalidate(llvm::Function&, llvm::PreservedAnalyses
const&, llvm::AnalysisManager<llvm::Function>::Invalidator&) + 389
6  clang-6.0                0x000000010b9bb80b
llvm::AnalysisManager<llvm::Function>::invalidate(llvm::Function&,
llvm::PreservedAnalyses const&) + 1035
7  clang-6.0                0x000000010b9bb19e
llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>
>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 846
8  clang-6.0                0x000000010c85bdf3
llvm::CGSCCToFunctionPassAdaptor<llvm::PassManager<llvm::Function,
llvm::AnalysisManager<llvm::Function> > >::run(llvm::LazyCallGraph::SCC&,
llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) + 851
9  clang-6.0                0x000000010c85ba42
llvm::detail::PassModel<llvm::LazyCallGraph::SCC,
llvm::CGSCCToFunctionPassAdaptor<llvm::PassManager<llvm::Function,
llvm::AnalysisManager<llvm::Function> > >, llvm::PreservedAnalyses,
llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&,
llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&,
llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) + 18
:
:
------------------------------------------------

Doing a git bisect identified the following commit as the issue.  This is
currently blocking our testing of other implementations. If a quick fix is not
possible please pull out this commit.


e87cf87e451df1e4b22a690a12fc56de7834d25a is the first bad commit
commit e87cf87e451df1e4b22a690a12fc56de7834d25a
Author: Sanjoy Das <sanjoy at playingwithpointers.com>
Date:   Thu Sep 28 02:45:42 2017 +0000

    Use a BumpPtrAllocator for Loop objects

    Summary:
    And now that we no longer have to explicitly free() the Loop instances, we
can
    (with more ease) use the destructor of LoopBase to do what
LoopBase::clear() was
    doing.

    Reviewers: chandlerc

    Subscribers: mehdi_amini, mcrosier, llvm-commits

    Differential Revision: https://reviews.llvm.org/D38201

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314375
91177308-0d34-0410-b5e6-96231b3b80d8

:040000 040000 81be8845db6347ef70ba74648575e49a36a4e101
48a946b7b2b840b6aaee4c68ff19eaec8c62ff68 M      include
:040000 040000 35b952670bb8e9d35412ff68b387230caaa2fa2b
757bb6d08738dcbf32fc63c549b57e8793bc04b0 M      lib
:040000 040000 9698ade32e5219741dacb5d824eaecc2f5ed7306
6f8a7f9c679741336fc2912030be4ea173c87952 M      test
:040000 040000 e0e2fce0dbb5dc3eccafac5f749747c1e559edf7
d39a1b6585a6094352008c8ea57a01f6135d200f M      unittests

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171004/eac73aa2/attachment.html>