[llvm-dev] Build polly-amd64-linux Failure

Tobias Grosser via llvm-dev llvm-dev at lists.llvm.org
Tue May 9 08:52:39 PDT 2017


On Tue, May 9, 2017, at 05:08 PM, Michael Kruse via llvm-dev wrote:
> 2017-05-06 16:46 GMT+02:00 Tobias Grosser <tobias at grosser.es>:
> > On Sat, May 6, 2017, at 04:28 PM, llvm.buildmaster at lab.llvm.org wrote:
> >> The Buildbot has detected a failed build on builder polly-amd64-linux
> >> while building polly.
> >> Full details are available at:
> >>  http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/6539
> >>
> >> Buildbot URL: http://lab.llvm.org:8011/
> >>
> >> Buildslave for this Build: grosser1
> >>
> >> Build Reason: scheduler
> >> Build Source Stamp: [branch trunk] 302339
> >> Blamelist: meinersbur
> >
> > Hi Michael,
> >
> > the recent commit caused a failure:
> >
> > /home/grosser/buildslave/polly-amd64-linux/llvm.src/tools/polly/test/DeLICM/reduction_overapproximate.ll:102:16:
> > error: expected string not found in input
> > ; APPROX-NEXT: new: { Stmt_reduction_inc[i0, i1] -> MemRef_A[2] : i0 <=
> > 3 and 0 <= i1 <= -2 + i0 };
> >                ^
> > <stdin>:62:2: note: scanning from here
> >  new: { Stmt_reduction_inc[i0, i1] -> MemRef_A[2] : 2 <= i0 <= 3 and 0
> >  <= i1 <= -2 + i0 };
> >
> > I have no idea where it comes from. On my machine (and my earlier tests)
> > show no issues. Any ideas?
> 
> No idea either. It worked reliably on the machines I tested with. I am
> not even sure how to debug this difference.

The sets we obtain are semantically identical, but have a different
representation. So it does not seem to be a correctness issue. Still, it
would be good if we can resolve this at some point.

Maybe open a bug report for now that we don't forget.

My first shot would be to compile a Release - no asserts of Polly and
see if the same results are obtained. My guess is that some of your
ASSERT statements cause isl to simplify constraints on the way, which
may not happen in a release build. If this is indeed the case, I do not
have a good answer how to address this.

Best,
Tobias


More information about the llvm-dev mailing list