assertions triggered during runtime build with trunk llvm

[Trass3r]

As I already reported in this thread I run into llvm assertions when it compiles druntime and phobos.
trunk llvm, 2.064 branch, EH patch, VS2013

In Debug mode:
Generating std/algorithm-debug.obj
Assertion failed: !N->getContext().pImpl->MDNodeSet.RemoveNode(N)
&& "Deleting a non-temporary uniqued node!", file
......\lib\IR\Metadata.cpp, line 296

In Release also:
Generating src/core/atomic.obj
Assertion failed: List && "Handle list is null?", file
......\lib\IR\Value.cpp, line 528

[Trass3r]

cmake.exe -G "Visual Studio 12 Win64" 
-DCMAKE_INSTALL_PREFIX=.../llvm/installed 
-DLLVM_TARGETS_TO_BUILD=X86
-DLLVM_BUILD_TOOLS=OFF -DLLVM_INCLUDE_TESTS=OFF 
-DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_APPEND_VC_REV=ON ..

cmake.exe -G "Visual Studio 12 Win64" 
-DCMAKE_INSTALL_PREFIX=.../ldc -DLLVM_ROOT_DIR=.../llvm/installed 
-DLIBCONFIG++_INCLUDE_DIR=../libconfig-1.4.9/lib 
-DLIBCONFIG++_LIBRARY="../libconfig-1.4.9/x64/Release/libconfig++.lib" 
..

plus compiler options for both

-DCMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO="/DEBUG /INCREMENTAL:NO /OPT:REF /OPT:ICF" -DCMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO="/DEBUG /INCREMENTAL:NO /OPT:REF /OPT:ICF" -DCMAKE_CXX_FLAGS="/DWIN32 /D_HAS_EXCEPTIONS=0 /MP /W3 /GR- /GS- /d2Zi+" -DCMAKE_CXX_FLAGS_DEBUG="/D_DEBUG /MDd /Z7 /Od /Ob2 /RTCs" -DCMAKE_CXX_FLAGS_RELWITHDEBINFO="/MD /Z7 /O2 /Gw /DNDEBUG

But it's also triggered without those. /d2Zi+ really makes a difference for debugging the release exe though.

[Trass3r]

llvm::ValueHandleBase::AddToExistingUseList(llvm::ValueHandleBase** List=0) Line 531
llvm::scc_iterator<llvm::CallGraph*,llvm::GraphTraits<llvm::CallGraph*>>::DFSVisitChildren() Line 158
llvm::scc_iterator<llvm::CallGraph*,llvm::GraphTraits<llvm::CallGraph*>>::GetNextSCC() Line 179
`anonymous namespace'::CGPassManager::runOnModule(llvm::Module& M=<struct at NULL>) Line 434
`anonymous namespace'::MPPassManager::runOnModule(llvm::Module& M={...}) Line 1625
llvm::legacy::PassManagerImpl::run(llvm::Module & M={...}) Line 1734
ldc_optimize_module(llvm::Module* M=0x00000000024a6d20) Line 400

[redstar]

I can reproduce the assertion. I'll fix this soon as VS2012 is my primary development tool.

[Trass3r]

Also the one that only happens in release mode?

[redstar]

Yes. It also happens on Linux. Not fixing this would be a release blocker once LLVM 3.5 is released.

[Trass3r]

Ok good. Also seems to happen with the 3.4 llvm branch.

[redstar]

Hm. This is a bit surprising.

[redstar]

The commit should correct the debug build issue.

[Trass3r]

With the 3.4 branch I get the following before and after the patch:

7>------ Build started: Project: phobos-ldc-debug, Configuration: RelWithDebInfo x64 ------
7>  Generating std/algorithm-debug.obj
7>  Assertion failed: (!F || F->getParent() == Mod) && "Function not in current module!", file ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 177
8>------ Build started: Project: phobos-ldc, Configuration: RelWithDebInfo x64 ------
8>  Generating std/algorithm.obj
8>  Assertion failed: (!F || F->getParent() == Mod) && "Function not in current module!", file ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 177


7>-------Build started: Project: phobos-ldc-debug, Configuration: RelWithDebInfo x64 ------
7>  Generating std/algorithm-debug.obj
7>  Assertion failed: (!F || F->getParent() == Mod) && "Function not in current module!", file ..\..\..\..\lib\Analysis\IPA\CallGraph.cpp, line 177
8>------ Build started: Project: phobos-ldc, Configuration: RelWithDebInfo x64 ------
8>  Generating std/algorithm.obj
8>  Assertion failed: VP.getPointer() == Next->VP.getPointer() && "Added to wrong list?", file ..\..\..\lib\IR\Value.cpp, line 534

[redstar]

My fix applies only for LLVM 3.5 and generating debug output. I still investigate the 3.4 branch failure.

[redstar]

I could not reproduce the assertion failure with LLVM 3.4 using a release build with assertions on mingw. I now try a MSVC build. Could it be a MSVC problem only?

[redstar]

Ok, I now get the failure in llvm::scc_iterator. (MSVC 2012, RelWithDebInfo configuration) But I still have no idea what happens here.

[Trass3r]

No clue either. Even with d2Zi+ the debug info is still too inconclusive.

[Trass3r]

module std.algorithm;
import std.functional, std.range, std.utf;

bool startsWith(alias pred = "a == b", R, E)(R doesThisStart, E withThis)
{
return doesThisStart.empty
        ? false
        : binaryFun!pred(doesThisStart.front, withThis);
}
uint endsWith()()
{
}
int cmp()()
{
}

ldc2 --output-o -c -I../runtime/druntime/src -I../runtime/druntime/src/gc std/algorithm.d
Assertion failed: VP.getPointer() == Next->VP.getPointer() && "Added to wrong list?", file llvm\lib\IR\Value.cpp, line 571

ldc2 --output-o -c -I../runtime/druntime/src -I../runtime/druntime/src/gc std/algorithm.d -g
Assertion failed: (!F || F->getParent() == &M) && "Function not in current module!", file llvm\lib\Analysis\IPA\CallGraph.cpp, line 149

[Trass3r]

Back on 3.5 trunk now. Had to remove the stdint.h in vcbuild btw to fix the build. Seems like even a module with 'int ff;' leads to one of the assertions.

objdir/bin/RelWithDebInfo/ldc2.exe --output-o -c -Ildcsrc/runtime/druntime/src -Ildcsrc/runtime/druntime/src/gc min.d -w -d -g
Assertion failed: List && "Handle list is null?", file llvm\lib\IR\Value.cpp, line 588

[Trass3r]

Just tried with the 2.065 branch again, llvm trunk, debug.

ldc2 --output-o -c -Ildcsrc/runtime/druntime/src -Ildcsrc/runtime/druntime/src/gc ldcsrc/runtime/druntime/src/core/atomic.d -ofldcsrc/objdir/runtime/src/core/atomic-debug.obj -w -d -g -disable-invariants

 llvm::verifyModule(const llvm::Module & M={...}, llvm::raw_ostream * OS=0x0000000000000000) Line 2574
 llvm::JumpInstrTables::runOnModule(llvm::Module & M={...}) Line 255
 llvm::FPPassManager::runOnFunction(llvm::Function & F={...}) Line 1545
 llvm::legacy::FunctionPassManagerImpl::run(llvm::Function & F={...}) Line 1494
 llvm::legacy::FunctionPassManager::run(llvm::Function & F={...}) Line 1413
 codegenModule(llvm::TargetMachine & Target={...}, llvm::Module & m={...}, llvm::raw_fd_ostream & out={...}, llvm::TargetMachine::CodeGenFileType fileType=CGFT_ObjectFile) Line 95
 writeModule(llvm::Module * m=0x0000000002475ae0, std::basic_string<char,std::char_traits<char>,std::allocator<char> > filename={...}) Line 247
 main(int argc=11, char * * argv=0x0000000000477b70) Line 1278

It treats JumpInstrTables like a FunctionPass and passes a Function instead of a Module cause FunctionPass *FP = getContainedPass(Index); in FPPassManager::runOnFunction does a static cast inside.

There are more module passes in the list. Coming from Target.addPassesToEmitFile in codegenModule.

[redstar]

Nice analysis. Any chance that you provide a pull request to fix it?

[Trass3r]

It seems to fix something but at least in release mode there are still various issues.
Also found out that r210903 changed AtomicCmpXchgInst requiring changes.

[redstar]

The change to AtomicCmpXchgInst is now fixed, too.

[Trass3r]

Nice currently looking into the assertion in stacktrace:263.

ldc2.exe  --output-o -c -Ildcsrc/runtime/druntime/src -Ildcsrc/runtime/druntime/src/gc ldcsrc/runtime/druntime/src/core/sys/windows/stacktrace.d -w -d -O3 -release -disable-invariants

Basically it's if(*symbol.Name.ptr) . In the 2nd if in DtoCastInt you then have a LoadInst with type array of char and no plain integer type. Don't know enough about llvm yet to fix it.

[redstar]

I think it is a problem in ldc - the pointer is not dereferenced. I constructed this small test case:

struct Foo
{
    char[1] bar;
}

bool checkBar(Foo* foo)
{
    return true && *foo.bar.ptr;
}

[dnadlinger]

@redstar: The problem seems to be that the LLVM type of _foo.bar.ptr is char[1] ([1 x i8]), not char (i8). That's because the frontend performs a very weird rewrite: !!(_foo).bar.

[dnadlinger]

@Trass3r, @redstar: Fix at #649.

[Trass3r]

Oh boy FINALLY found out what the heck is going on in release mode:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-March/039140.html
If llvm is built with assertions the user code must also undefine NDEBUG.
They have to do something about that.

Now it's just compile errors remaining: #651

[Trass3r]

http://llvm.org/bugs/show_bug.cgi?id=14885