pred_iterator out of range

[llvmbot]

Bugzilla Link	2207
Resolution	FIXED
Resolved on	Mar 06, 2010 13:58
Version	unspecified
OS	MacOS X
Reporter	LLVM Bugzilla Contributor
CC	@nlewycky

Extended Description

This bug occurs when building a bootstrap (i.e., "I'm a n00bie that just checked llvm out of the svn repo") version of llvm. I was able to narrow the bug down to two before/after versions:

47988: No assert
47989: Assert gets triggered during 'make check'

To reproduce:
a) Install XCode 2.5 on a x86 Darwin machine (Mac Powerbook with Tiger)
b) check out version 47989 out of the svn repo
c) ./configure --enable-optimized
d) make
e) make check

During make check, the following assert gets triggered in many test cases, not just one:

Support/CFG.h:64: failed assertion `!It.atEnd() && "pred_iterator out of range!"

PS: If I had the time to track this down right now, I would.

[llvmbot]

Oh, yeah: It's in TOT.

[lattner]

Nicholas, this looks like your patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080303/059255.html

Maybe we should revert it until this is sorted out?

[nlewycky]

I've got over it with Chandler. As far as we can tell, Mac OS X's GCC is miscompiling LLVM.

[lattner]

Is there a workaround, or should that version of xcode be added to the broken compilers list?

[llvmbot]

Putting XCode 2.5's gcc on the "broken compilers" list is probably going to be a mistake, if not a grave error. If that is done, then anyone running Tiger will not be able to participate in LLVM until a workaround or fixed compiler is released with the next 2.x series in XCode releases.

Downgrading to XCode 2.4 isn't helpful either. Same bug pops up.

Installing gcc 4.2 out of MacPorts does get things to compile, but the consequence is actually getting things to run afterward with a non-standard compiler.

[llvmbot]

Incidentally, not all of us can run Leopard until certain security tests are passed and Leopard is blessed. Upgrading is not exactly an option.

[lattner]

I completely understand, and don't want to go there, hence my desire to find a work around :). Is there any way to change the code so that this bug doesn't get triggered?

[nlewycky]

I don't know of any way to work around the bug. The problem disappears when we add -g to the gcc command line. Of course, I can't reproduce it on Linux at all so I'm pretty much stuck.

Then again, if the release is coming up soon (in May), we could remove the unfinished 'unwinds to' support from HEAD and release a version that will compile correctly.

[llvmbot]

I don't know of any way to work around the bug. The problem disappears when we
add -g to the gcc command line. Of course, I can't reproduce it on Linux at all
so I'm pretty much stuck.

Then again, if the release is coming up soon (in May), we could remove the
unfinished 'unwinds to' support from HEAD and release a version that will
compile correctly.

I'm looking into compiling with OPTIMIZE_OPTION="-O2 -g" (-O3 -g doesn't result in debug-able code) and seeing what the problem can be tracked to. It seems to me, however, from just inspecting the code, that one workaround might just be assigning end() to the iterator if the rest of the while loop's conditions fail (force the iterator to end() as a workaround.)

Just a thought -- might be able to get some hack time tonight if family commitments allow (my brother and his family are in town.)

[llvmbot]

Workaround for pred_iterator assert

[llvmbot]

Tracked down the trigger for the pred_iterator assert to llvm::isCriticalEdge in BreakCriticalEdges.cpp. The patch seems to work around the gcc 4.0.1 bug and 'make check' runs through to completion.

I'll commit it (unless something else untoward happens, at which point it's easy to back out).