Crash on AU.addRequired<LoopInfo>(); in LLVM pass - llvm

I have a simple Function pass, and I am trying to get loop info in the code. But when I try to add AU.addRequired() in getAnalysisUsage(), the module crashes. This happens even before getAnalysis() is called. It is a dynamically loaded pass (.so).
namespace
{
class TestPass : public FunctionPass
{
public:
static char ID;
TestPass() : FunctionPass(ID) {}
virtual void getAnalysisUsage(AnalysisUsage &AU) const
{
AU.addRequired<LoopInfo>();
AU.setPreservesAll();
}
bool runOnFunction(Function &F) override
{
errs() << F.getName() << " : " << F.getBasicBlockList().size() << "\n";
// LoopInfo &LI = getAnalysis<LoopInfo>();
return false;
}
};
}
char TestPass::ID = 0;
static RegisterPass<TestPass> X("TestPass", "Test pass");
// register pass for clang use
static void registerTestPassPass(const PassManagerBuilder &, PassManagerBase &PM)
{
PM.add(new TestPass());
}
static RegisterStandardPasses RegisterTestPassPass(PassManagerBuilder::EP_EarlyAsPossible , registerTestPassPass);
Here is the stack trace.
[armeabi-v7a] Compile thumb : test <= test.c
Pass 'Test pass' is not initialized.
Verify if there is a pass dependency cycle.
Required Passes:
0 clang 0x0000000001492ec2 llvm::sys::PrintStackTrace(_IO_FILE*) + 34
1 clang 0x0000000001490f61
2 libpthread.so.0 0x00002b15cbb4e340
3 clang 0x00000000011c86f7 llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 343
4 clang 0x00000000019c0401 llvm::PassManagerBuilder::addExtensionsToPM(llvm::PassManagerBuilder::ExtensionPointTy, llvm::legacy::PassManagerBase&) const + 225
5 clang 0x00000000019c054a llvm::PassManagerBuilder::populateFunctionPassManager(llvm::legacy::FunctionPassManager&) + 26
6 clang 0x0000000001837de3 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 1171
7 clang 0x000000000182a47f
8 clang 0x0000000001bdf043 clang::ParseAST(clang::Sema&, bool, bool) + 483
9 clang 0x0000000001603ba6 clang::FrontendAction::Execute() + 118
10 clang 0x00000000015e47b8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 280
11 clang 0x0000000001673b41 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1921
12 clang 0x0000000000820358 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 1320
13 clang 0x00000000007fceaa main + 8298
14 libc.so.6 0x00002b15cc7b6ec5 __libc_start_main + 245
15 clang 0x000000000081e5d9
Am I missing something? Any help would be appreciated.

Found the solution. The code was missing creation of a new LoopInfo() object in order to call the LoopInfo pass.
// register pass for clang use
static void registerTestPassPass(const PassManagerBuilder &, PassManagerBase &PM)
{
PM.add(new LoopInfo());
PM.add(new TestPass());
}

Related

Crash in boost exception code while building ec string

I'm trying to figure out a crash dump that I got when initiating a boost implementation of unix domain socket.
What's strange about it is that the relevant frame is when it parsed the ec.what() which is a function that basically create a string message ...
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 P 0x104919660 boost::system::error_code::what() const (in P_arm64.dsym) + 528 + 251488
1 P 0x104919654 boost::system::error_code::what() const (in P_arm64.dsym) + 516 + 251476
2 P 0x104918ea8 boost::system::system_error::system_error(boost::system::error_code const&, char const*) (in P_arm64.dsym) + 308 + 249512
3 P 0x104adbd10 boost::asio::basic_socket<boost::asio::local::stream_protocol, boost::asio::any_io_exec
utor>::connect(boost::asio::local::basic_endpoint<boost::asio::local::stream_protocol> const&) (in P_arm64.dsym) + 1808 + 2096400
(--> this is my c'tor that initiate the unix domain socket)
4 P 0x104ad9ed4 service::api::Instance(std::__1::function<void (std::__1::
Besides the callstack, I could generate a crash file with a crash reason
Termination Reason: Namespace SIGNAL, Code 10 Bus error: 10
Terminating Process: exc handler [2253]
VM Region Info: 0x107008fa8 is in 0x107006000-0x10705e000; bytes after start: 12200 bytes before end: 348247
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
__TEXT 10664e000-107006000 [ 9952K] r-x/r-x SM=COW ...s/MacOS/P
---> __DATA_CONST 107006000-10705e000 [ 352K] r--/rw- SM=COW ...s/MacOS/P
__DATA 10705e000-107072000 [ 80K] rw-/rw- SM=COW ...s/MacOS/P
So It seems like when the ec message is created, we attempt to write a read only memory (DATA_CONST) . I think that this is the problematic code :
source_location const & location() const BOOST_NOEXCEPT
{
BOOST_STATIC_CONSTEXPR source_location loc;
return lc_flags_ >= 4? *reinterpret_cast<source_location const*>( lc_flags_ &~ static_cast<boost::uintptr_t>( 1 ) ): loc;
}
which is called from here
std::string what() const
{
std::string r = message();
r += " [";
r += to_string();
if( has_location() )
{
r += " at ";
--> r += location().to_string();
}
r += "]";
return r;
}
However, i don't understand where do we attempt to write to the const expression 'loc'... any idea what may be the reason ?

Exception on date::locate_zone with existing timezone

I've following code:
for (const date::time_zone& tz: date::get_tzdb().zones) {
std::cout << tz.name() << std::endl;
}
std::cout << __LINE__ << std::endl;
auto zone = date::locate_zone("Europe/Berlin");
std::cout << __LINE__ << std::endl;
Which is crashing in line 5 (auto zone...)
The output is:
...
Europe/Belfast
Europe/Belgrade
Europe/Berlin
Europe/Bratislava
Europe/Brussels
...
Zulu
tzdata.zi
40
12:35:55: Das Programm ist abgestürzt.
The 40 is the line in my code.
As I understood by the documentation, locate_zone("Europe/Berlin") should only crash when the time zone isn't existing, but as you can see in the result, it exists.
What I'm doing wrong? Where is my mistake?
EDIT:
Btw, I'm using g++ 11 with C++20 mode.
I also added a try-catch block
try {
auto zone = date::get_tzdb().locate_zone("Europe/Berlin");
std::cout << __LINE__ << std::endl;
} catch (const std::exception &e) {
std::cout << e.what() << std::endl;
}
But it isn't arriving the catch block:
W-SU
WET
Zulu
tzdata.zi
40
20:33:24: Das Programm ist abgestürzt.
Edit 2:
I updated to the newest master branch version (3.0.1) and created an debug version of the library.
In file tz.cpp the error is on line 3592:
3585: const time_zone*
3586: #if HAS_STRING_VIEW
3587: tzdb::locate_zone(std::string_view tz_name) const
3588: #else
3589: tzdb::locate_zone(const std::string& tz_name) const
3590: #endif
3591: {
3592: auto zi = std::lower_bound(zones.begin(), zones.end(), tz_name,
3593: #if HAS_STRING_VIEW
The ones with auto zi = ...
Stack trace:
1 __memcmp_sse4_1 memcmp-sse4.S 869 0x7ffff1734b94
2 std::char_traits<char>::compare char_traits.h 361 0x4c9180
3 std::basic_string_view<char, std::char_traits<char>>::compare string_view 314 0x7fffef997311
4 std::operator<=><char, std::char_traits<char>>(std::basic_string_view<char, std::char_traits<char>>, std::__type_identity<std::basic_string_view<char, std::char_traits<char>>>::type) string_view 559 0x7fffef99728f
5 operator() tz.cpp 3599 0x7fffef98ce55
6 __gnu_cxx::__ops::_Iter_comp_val<date::tzdb::locate_zone(std::string_view) const::<lambda(const date::time_zone&, const string_view&)>>::operator()<__gnu_cxx::__normal_iterator<const date::time_zone *, std::vector<date::time_zone>>, const std::basic_string_view<char>>(__gnu_cxx::__normal_iterator<date::time_zone const *, std::vector<date::time_zone>>, const std::basic_string_view<char, std::char_traits<char>> &) predefined_ops.h 196 0x7fffef98ecb4
7 std::__lower_bound<__gnu_cxx::__normal_iterator<const date::time_zone *, std::vector<date::time_zone>>, std::basic_string_view<char>, __gnu_cxx::__ops::_Iter_comp_val<date::tzdb::locate_zone(std::string_view) const::<lambda(const date::time_zone&, const string_view&)>>>(__gnu_cxx::__normal_iterator<date::time_zone const *, std::vector<date::time_zone>>, __gnu_cxx::__normal_iterator<date::time_zone const *, std::vector<date::time_zone>>, const std::basic_string_view<char, std::char_traits<char>> &, __gnu_cxx::__ops::_Iter_comp_val<date::tzdb::locate_zone(std::string_view) const::<lambda(const date::time_zone&, const string_view&)>>) stl_algobase.h 1464 0x7fffef98ed24
8 std::lower_bound<__gnu_cxx::__normal_iterator<const date::time_zone *, std::vector<date::time_zone>>, std::basic_string_view<char>, date::tzdb::locate_zone(std::string_view) const::<lambda(const date::time_zone&, const string_view&)>>(__gnu_cxx::__normal_iterator<date::time_zone const *, std::vector<date::time_zone>>, __gnu_cxx::__normal_iterator<date::time_zone const *, std::vector<date::time_zone>>, const std::basic_string_view<char, std::char_traits<char>> &, struct {...}) stl_algo.h 2021 0x7fffef98e786
9 date::tzdb::locate_zone tz.cpp 3592 0x7fffef98cf92
The issue was a C++ Version mismatch. The used library, which includes tz date, is compiled with C++-14. My app is compiled with C++-20. In C++-14 string_view does not exist, causing that error to occur.
When I compile the library with C++-17 or C++-20, it works.
The library itself not being usable is another issue that is not related to this question.

parameter value lost after call new_allocator in c++

I meet a strange behavior for a c++11 program, and can not figure out what is going wrong. please gave me some advises. thanks.
basically, it is a OpenCL program.
struct memory_layout
{
public:
memory_layout(managed_device d);
scalar<int> s;
};
memory_layout::memory_layout(managed_device d) :
s(d)
{
}
class doer
{
public:
doer();
void go();
private:
managed_device dev;
memory_layout mem;
};
doer::doer():
dev(find_CPU()),
mem(dev)
{
}
void doer::go()
{
task t = copy(10,mem.s);
}
int main(){
doer d;
d.go();
return 0;
}
when it runs to copy function, it has "Segmentation Fault".
Here is the def of copy:
template <typename T>
task copy(const T& source, scalar<T>& sink, const std::vector<task>& deps = {} )
{
return sink.device().create_task( profile::copy<T>(source, sink), deps );
}
When I use gdb to debug:
Breakpoint 1, doer::go (this=0x7fffffffdc90) at main.cpp:79
79 task t = copy(10,mem.s); // device() original be 0x60f0d0
(gdb) p mem.s.device()
$1 = (cppcl::opencl_1_2::device::managed_device &) #0x7fffffffdc60: {_device = 0x60f0d0}
(gdb) s
std::vector<unsigned long, std::allocator<unsigned long> >::vector (this=0x7fffffffdc50) at /usr/include/c++/4.8.3/bits/stl_vector.h:249
249 : _Base() { }
(gdb)
std::_Vector_base<unsigned long, std::allocator<unsigned long> >::_Vector_base (this=0x7fffffffdc50)
at /usr/include/c++/4.8.3/bits/stl_vector.h:125
125 : _M_impl() { }
(gdb)
std::_Vector_base<unsigned long, std::allocator<unsigned long> >::_Vector_impl::_Vector_impl (this=0x7fffffffdc50)
at /usr/include/c++/4.8.3/bits/stl_vector.h:87
87 : _Tp_alloc_type(), _M_start(0), _M_finish(0), _M_end_of_storage(0)
(gdb)
std::allocator<unsigned long>::allocator (this=0x7fffffffdc50) at /usr/include/c++/4.8.3/bits/allocator.h:113
113 allocator() throw() { }
(gdb)
__gnu_cxx::new_allocator<unsigned long>::new_allocator (this=0x7fffffffdc50) at /usr/include/c++/4.8.3/ext/new_allocator.h:80
warning: Source file is more recent than executable.
80
(gdb)
std::_Vector_base<unsigned long, std::allocator<unsigned long> >::_Vector_impl::_Vector_impl (this=0x7fffffffdc50)
at /usr/include/c++/4.8.3/bits/stl_vector.h:88
88 { }
(gdb)
cppcl::opencl_1_2::device::copy<int> (source=#0x7fffffffdc6c: 10, sink=..., deps=std::vector of length 0, capacity 0)
at /usr/include/cppcl/1.2/device/buffer_templates.h:1233
warning: Source file is more recent than executable.
1233 return sink.device().create_task( profile::copy<T>(source, sink), deps );
(gdb) p sink.device()
$2 = (cppcl::opencl_1_2::device::managed_device &) #0x7fffffffdc60: {_device = 0x0}
after I step into the copy function, it first build the "deps" parameter, and then, the _device value changed to 0x0. I could not figure out why this happy?
thanks for giving me some suggestions.
I'm assuming that you're not asking what's wrong with your code, that you're only asking how to figure out yourself what's wrong with your code. Otherwise, there's not enough information in your question.
This is a good first step in debugging. You've found clear indication that one value in memory is being changed. You've found a concrete object managed_device at address 0x7fffffffdc60 that contains a value that gets changed somehow.
Let me use a simple complete program:
#include <stdio.h>
int *p;
void f() {
++*p;
}
int main() {
int i = 3;
p = &i;
printf("%d\n", i); // i is 3 here.
f();
printf("%d\n", i); // Huh? i is 4 here.
}
Now, of course it is completely and utterly obvious why i changes in this program, but let's suppose that I completely overlooked it anyway.
If I set a breakpoint on line 13 (the call to f), and inspect i, I see that it is still 3.
Breakpoint 1, main () at test.cc:13
13 f();
(gdb) p i
$1 = 3
No surprise there. And I've already determined that the value will at some unknown point in the future get changed, I just don't know when.
I can now use the watch instruction to monitor that variable for changes:
(gdb) watch i
Hardware watchpoint 2: i
and then continue execution:
(gdb) cont
Continuing.
Hardware watchpoint 2: i
Old value = 3
New value = 4
f () at test.cc:7
7 }
(gdb) bt
#0 f () at test.cc:7
#1 0x004011e9 in main () at test.cc:13
Now, I have seen that the code that modified i was just before the closing brace in f.
This is what you'll need to do with your own code. It'll be a bit more complex than in this simple example, but you should be able to use it for your own code as well.

LLVM assertion failure using AliasAnalysis in Module pass

I am running into an issue trying to use AliasAnalysis from within a module pass (LLVM 3.4). This seems to be a fairly common issue with two main solutions, but I haven't been able to get it to work.
With the following simple test program:
#include <stdio.h>
static int gX;
void f() {
gX = 1;
}
int main() {
printf("Hello.\n");
return 0;
}
Compiled like this: clang++ -O0 -c -emit-llvm -o test.bc test.cpp
And my simple pass:
class DebugPass : public ModulePass {
public:
static char ID;
DebugPass() : ModulePass(ID) {}
virtual void getAnalysisUsage(AnalysisUsage &AU) const {
AU.setPreservesAll();
AU.addRequired<AliasAnalysis>();
}
virtual bool runOnModule(Module &M) {
for (Module::iterator fit = M.begin(), fite = M.end(); fit != fite; ++fit) {
Function *F = fit;
if (F->isDeclaration()) continue;
errs() << "Getting AA for " << F->getName() << "\n";
AliasAnalysis &AA = getAnalysis<AliasAnalysis>(*F);
}
return false;
}
}
char DebugPass::ID = 0;
static RegisterPass<DebugPass> X("testdebug", "Debugging pass", false, false);
And by invoking my pass like this: opt -load ../Debug+Asserts/lib/TestLib.dylib -basicaa -testdebug < test.bc > /dev/null
I am seeing the following assertion failure:
Getting AA for _Z1fv
Assertion failed: (FPP && "Unable to find on the fly pass"), function getOnTheFlyPass, file LegacyPassManager.cpp, line 1682.
...
6 opt 0x0000000102e5ba62 abort + 18
7 opt 0x0000000102e5ba41 __assert_rtn + 129
8 opt 0x0000000102d94820 (anonymous namespace)::MPPassManager::getOnTheFlyPass(llvm::Pass*, void const*, llvm::Function&) + 144
9 opt 0x0000000102d949cf non-virtual thunk to (anonymous namespace)::MPPassManager::getOnTheFlyPass(llvm::Pass*, void const*, llvm::Function&) + 63
10 opt 0x0000000102d8ed4e llvm::AnalysisResolver::findImplPass(llvm::Pass*, void const*, llvm::Function&) + 78
11 TestLib.dylib 0x0000000104ba9bac llvm::AliasAnalysis& llvm::Pass::getAnalysisID<llvm::AliasAnalysis>(void const*, llvm::Function&) + 236
12 TestLib.dylib 0x0000000104b9eef6 llvm::AliasAnalysis& llvm::Pass::getAnalysis<llvm::AliasAnalysis>(llvm::Function&) + 134
13 TestLib.dylib 0x0000000104bdc287 DebugPass::runOnModule(llvm::Module&) + 215
Can anyone offer some insight into what is going wrong?
Edit: Here is the pass structure via -debug-pass=Structure:
Pass Arguments: -targetlibinfo -datalayout -notti -basictti -x86tti -no-aa -basicaa -testdebug -preverify -domtree -verify
Target Library Information
Data Layout
No target information
Target independent code generator's TTI
X86 Target Transform Info
No Alias Analysis (always returns 'may' alias)
Basic Alias Analysis (stateless AA impl)
ModulePass Manager
Debugging pass
FunctionPass Manager
Preliminary module verification
Dominator Tree Construction
Module Verifier
Bitcode Writer
Is it significant that my debugging pass occurs before the FunctionPass manager? I am not practiced in interpreting the pass structure output.

Range-based-for implementation compiles in g++ but not in clang++

The following range-based-for snippet compiles fine in g++ 4.6.1, but not with clang++ version 3.1 (trunk 151577) on oneiric amd64.
A very basic range-based for (eg std::vector) seems to work fine, so something is wrong with my implementation for my own enumerations.
I am looking for a sanity-check or a work-around.
If someone has a work-around for range-based-for that clang++ is happy with, that would be fantastic.
template< typename E >
class Enum
{
public:
Enum() : m_e( E::Last ) { }
Enum( E t ) : m_e( t ) { }
E operator()() const
{
return m_e;
}
public:
class Iterator
{
public:
Iterator( int val ) : m_val( val ) { }
E operator*( void ) const
{
return (E) m_val;
}
void operator++( void )
{
++m_val;
}
bool operator!=( Iterator rhs ) const
{
return m_val != rhs.m_val;
}
private:
int m_val;
};
private:
E m_e;
};
enum class eCOLORS
{
kBLUE=0, kGREEN, kRED, kPURPLE,
First=kBLUE, Last=kPURPLE
};
Enum<eCOLORS>::Iterator begin(const Enum<eCOLORS>& b)
{
return Enum<eCOLORS>::Iterator( (int)(eCOLORS::First ));
}
Enum<eCOLORS>::Iterator end(const Enum<eCOLORS>& b)
{
return Enum<eCOLORS>::Iterator( (int)(eCOLORS::Last ));
}
int main()
{
Enum<eCOLORS> e;
// for( const auto x : Enum<eCOLORS>() )
for( auto it=begin(e);
it!=end(e); ++it )
{
}
}
The errors are listed below
clang++ -g -std=c++0x \
sandbox.cpp -o sandbox
clang: /mnt/home/foobar/src/llvm/tools/clang/lib/AST/Decl.cpp:1001: bool clang::NamedDecl::isCXXInstanceMember() const: Assertion `isCXXClassMember() && "checking whether non-member is instance member"' failed.
0 clang 0x0000000001aecc4f
1 clang 0x0000000001aed179
2 libpthread.so.0 0x00002aeeaeda1060
3 libc.so.6 0x00002aeeaf98b3a5 gsignal + 53
4 libc.so.6 0x00002aeeaf98eb0b abort + 379
5 libc.so.6 0x00002aeeaf983d4d __assert_fail + 221
6 clang 0x0000000000ed8f9e clang::NamedDecl::isCXXInstanceMember() const + 174
7 clang 0x0000000000a51095 clang::Sema::CheckQualifiedMemberReference(clang::Expr*, clang::QualType, clang::CXXScopeSpec const&, clang::LookupResult const&) + 213
8 clang 0x0000000000a55520 clang::Sema::BuildMemberReferenceExpr(clang::Expr*, clang::QualType, clang::SourceLocation, bool, clang::CXXScopeSpec const&, clang::SourceLocation, clang::NamedDecl*, clang::LookupResult&, clang::TemplateArgumentListInfo const*, bool) + 672
9 clang 0x0000000000a518d4 clang::Sema::BuildMemberReferenceExpr(clang::Expr*, clang::QualType, clang::SourceLocation, bool, clang::CXXScopeSpec&, clang::SourceLocation, clang::NamedDecl*, clang::DeclarationNameInfo const&, clang::TemplateArgumentListInfo const*) + 772
10 clang 0x0000000000b50378
11 clang 0x0000000000b58a19
12 clang 0x0000000000b56362
13 clang 0x0000000000b4e87b clang::Sema::SubstExpr(clang::Expr*, clang::MultiLevelTemplateArgumentList const&) + 75
14 clang 0x0000000000b64a69 clang::Sema::SubstInitializer(clang::Expr*, clang::MultiLevelTemplateArgumentList const&, bool) + 169
15 clang 0x0000000000b6d57f clang::Sema::InstantiateMemInitializers(clang::CXXConstructorDecl*, clang::CXXConstructorDecl const*, clang::MultiLevelTemplateArgumentList const&) + 1135
16 clang 0x0000000000b6cb13 clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation, clang::FunctionDecl*, bool, bool) + 2307
17 clang 0x0000000000b6dadd clang::Sema::PerformPendingInstantiations(bool) + 461
18 clang 0x00000000008e0bb3 clang::Sema::ActOnEndOfTranslationUnit() + 419
19 clang 0x00000000008757d0 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 112
20 clang 0x00000000008727c6 clang::ParseAST(clang::Sema&, bool) + 326
21 clang 0x000000000075623e clang::CodeGenAction::ExecuteAction() + 958
22 clang 0x0000000000612f3d clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 957
23 clang 0x00000000005fb55a clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3098
24 clang 0x00000000005f17ce cc1_main(char const**, char const**, char const*, void*) + 5918
25 clang 0x00000000005f7679 main + 729
26 libc.so.6 0x00002aeeaf97630d __libc_start_main + 237
27 clang 0x00000000005effe9
Stack dump:
0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name sandbox.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -momit-leaf-frame-pointer -g -resource-dir /usr/local/bin/../lib/clang/3.1 -I /home/kfeng/dev/pitbull/cpp/inc/ -I /home/kfeng/src/stlsoft/include/ -I /home/kfeng/src/gtest/include/ -I /home/kfeng/src/gmock/include/ -I /home/kfeng/src/pantheios/include/ -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward -internal-isystem /usr/local/include -internal-isystem /usr/local/bin/../lib/clang/3.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++0x -fdeprecated-macro -fdebug-compilation-dir /home/kfeng/dev/pitbull/cpp/sbx -ferror-limit 19 -fmessage-length 181 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/sandbox-0nnyL0.o -x c++ sandbox.cpp
1. <eof> parser at end of file
2. sandbox.cpp:5:2: instantiating function definition 'Enum'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information.
clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/sandbox-Fp11tf.ii
clang: note: diagnostic msg: /tmp/sandbox-Fp11tf.sh
This compiles for me with the stable release of clang. Looks like it's a bug in trunk.
% clang --version
clang version 3.0 (tags/RELEASE_30/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
% clang++ -o test test.cc -std=c++0x
%