[cfe-dev] Crash during template instantiation

[Christopher Weaver]

While playing around with the newest version of Boost.Thread (which I was hoping but not entirely expecting to fully work) I stumbled across something which made clang crash. After multidelta finished with my input I'm not sure that it's still the same crash at all, but it is a crash, so I thought I'd report it. Here's the condensed test case which produces it:

$ cat crash_test3.ii
template <typename T>
class foo{
	undefined_type a;
	public:
	foo():a(T()){}
};

int main(){
	foo<int> f;
	return(0);
}

And here's the resulting output:
$ clang++ -v -c -O0 -emit-llvm crash_test3.ii 
clang version 2.8 (trunk 112506)
Target: x86_64-apple-darwin10
Thread model: posix
 "/Users/christopher/LLVM/llvm/Release+Asserts/bin/clang" -cc1 -triple x86_64-apple-darwin10.0.0 -emit-llvm-bc -disable-free -main-file-name crash_test3.ii -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -v -resource-dir /Users/christopher/LLVM/llvm/Release+Asserts/lib/clang/2.8 -O0 -ferror-limit 19 -fmessage-length 202 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o crash_test3.o -x c++-cpp-output crash_test3.ii
clang -cc1 version 2.8 based upon llvm 2.8svn hosted on x86_64-apple-darwin10
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.2.1
 /usr/include/c++/4.2.1/i686-apple-darwin10/x86_64
 /usr/include/c++/4.2.1/backward
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/i686-apple-darwin8
 /usr/include/c++/4.0.0/backward
 /usr/local/include
 /Users/christopher/LLVM/llvm/Release+Asserts/lib/clang/2.8/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
crash_test3.ii:3:2: error: unknown type name 'undefined_type'
        undefined_type a;
        ^
0  clang             0x0000000100de1eb2 PrintStackTrace(void*) + 34
1  clang             0x0000000100de2369 SignalHandler(int) + 793
2  libSystem.B.dylib 0x00007fff8036e35a _sigtramp + 26
3  libSystem.B.dylib 0x00000001016107a1 _sigtramp + 2167022689
4  clang             0x00000001003f7498 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 1848
5  clang             0x00000001003f7fc3 clang::Sema::PerformPendingInstantiations(bool) + 643
6  clang             0x0000000100262f7a clang::Sema::ActOnEndOfTranslationUnit() + 58
7  clang             0x0000000100250895 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 37
8  clang             0x000000010021ca40 clang::ParseAST(clang::Sema&, bool) + 720
9  clang             0x00000001001ed12b clang::CodeGenAction::ExecuteAction() + 779
10 clang             0x000000010003ecd9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 825
11 clang             0x00000001000204e3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1795
12 clang             0x0000000100019dec cc1_main(char const**, char const**, char const*, void*) + 5196
13 clang             0x000000010001d077 main + 791
14 clang             0x000000010001898c start + 52
Stack dump:
0.	Program arguments: /Users/christopher/LLVM/llvm/Release+Asserts/bin/clang -cc1 -triple x86_64-apple-darwin10.0.0 -emit-llvm-bc -disable-free -main-file-name crash_test3.ii -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.14 -v -resource-dir /Users/christopher/LLVM/llvm/Release+Asserts/lib/clang/2.8 -O0 -ferror-limit 19 -fmessage-length 202 -stack-protector 1 -fblocks -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o crash_test3.o -x c++-cpp-output crash_test3.ii 
1.	<eof> parser at end of file
2.	crash_test3.ii:5:2: instantiating function definition 'foo'
clang: error: clang frontend command failed due to signal 11 (use -v to see invocation)

The code is clearly not well formed, and clang spots the problem, but seems to try to go ahead anyway. I looked through Bugzilla, and I didn't see anything quite like this. Should I file a bug there?

	Chris Weaver