Shorter command that probably will repro this on posix too (still building a new enough clang to check):

"D:\src\llvm-ninja-rel64\bin\clang-cl.exe" "-cc1" "-triple" "i386-pc-windows-msvc" "-emit-obj" "-gline-tables-only" "-O2" "-std=c++11" "-fms-extensions" "-fms-compatibility" "-fdelayed-template-parsing" "-x" "c++" -w foo.ii

Yup, reproduces on posix too. Delta is running now, but the file is pretty big and takes ~5s per run, so it'll likely take several hours. If you see what's wrong without getting a reduced repro, you might want to not wait for the reduced repro :-)

reduce testcase
clang -cc1 -triple i386-pc-windows-msvc -emit-llvm-bc -gline-tables-only foo.ii -o test.bc
opt test.bc -o test2.bc -sroa
opt test2.bc -o test3.bc -inline
llc test3.bc #crashes

Simpler test case

Created attachment 13638 [details]
Simpler test case

Build with -O2 -g for this one.

reduced.cc
This generates far less IR, and still generates the same assertion.

reduced.cc
Now occurs without optimizations.

normal c++ program, no objective-c blocks or nothin', no optimizations needed to trigger:
template struct c {
c();
template attribute((always_inline)) c(c) {}
};
struct {
c v = c();
} o;

*** Bug llvm/llvm-bugzilla-archive#22114 has been marked as a duplicate of this bug. ***

Here's the reduction I arrived at, doesn't use blocks, any always_inline attributes, or even templates:

$ cat repro.ii
class _String_val {
union _Bxty { int i; } _Bx;
};
struct string : public _String_val {
string(const char *_Ptr) : _String_val() {}
};

int ConvertIPv4NumberToIPv6Number(int);
struct IPEndPoint {
IPEndPoint();
IPEndPoint(const int &address, int port);
const int &address() const {}
};

struct SourceAddressTokenTest {
SourceAddressTokenTest()
: ip4_dual_(ConvertIPv4NumberToIPv6Number(ip4_.address()), 1) {}
const string kPrimary = "";
IPEndPoint ip4_;
IPEndPoint ip4_dual_;
} s;
$ /Users/thakis/src/llvm-build/bin/clang "-cc1" "-triple" "i386-pc-windows-msvc" "-emit-obj" "-gline-tables-only" "-O2" "-std=c++11" "-fms-extensions" "-fms-compatibility" "-fdelayed-template-parsing" "-x" "c++" -w repro.ii
Assertion failed: (DISubprogram(Scope).describes(MF->getFunction())), function getOrCreateRegularScope, file /Users/thakis/src/llvm-svn/lib/CodeGen/LexicalScopes.cpp, line 179.
0 clang 0x00000001036b4839 llvm::sys::PrintStackTrace(__sFILE*) + 57
1 clang 0x00000001036b500b SignalHandler(int) + 571

I reverted r225085 in r225361. This made the assert I was seeing go away. Do others still see their asserts?

I tried some of the other reductions on this bug, they don't crash for me anymore either. I'll mark this as closed; shout if you're still seeing it.

The State.cpp issue is still present -- inlining of a global constructor.

Huh strange, that was one of the ones I tried:

$ bin/clang -cc1 -w -triple i386-pc-windows-msvc -O2 -emit-obj -g ~/Downloads/State-fc3936.cpp
$ bin/clang -cc1 -w -triple i386-pc-windows-msvc -emit-obj -g ~/Downloads/State-fc3936.cpp
$ bin/clang -cc1 -w -O2 -emit-obj -g ~/Downloads/State-fc3936.cpp
$ # no crashes

I tried a few more flag combinations I could think of. What command are you running to see a crash?

$ bin/clang --version
clang version 3.6.0 (trunk 225408)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

Huh strange, that was one of the ones I tried:

$ bin/clang -cc1 -w -triple i386-pc-windows-msvc -O2 -emit-obj -g
~/Downloads/State-fc3936.cpp
$ bin/clang -cc1 -w -triple i386-pc-windows-msvc -emit-obj -g
~/Downloads/State-fc3936.cpp
$ bin/clang -cc1 -w -O2 -emit-obj -g ~/Downloads/State-fc3936.cpp
$ # no crashes

I tried a few more flag combinations I could think of. What command are you
running to see a crash?

$ bin/clang --version
clang version 3.6.0 (trunk 225408)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

Hm. Difference in the way constructors are done, maybe?

clang -O2 -g -target x86_64-linux -c State-fc3936.cpp

Reverted in r225555.

Sorry for the delay - been a busy week.

Between this bug and the review thread I have 4 crash test cases, one that was resolved by Nico reverting one of the subsequent patches, the other 3 still crash until I submitted that revert. I'll work up more isolated test cases for them and then see about fixing them before resubmitting this patch.

If anyone else happens across any more reductions it'd be great for me to have them so I can address/verify them before recommitting.

Here's another testcase:

struct A {
A(int);
~A() { this->m_fn1(); }
void m_fn1();
};

struct Class {
Class(A);
};
template struct B {
static Class *m_theClass;
void m_fn1() { B::m_theClass; }
};

template
Class *B::m_theClass = new Class(0);

$ clang -cc1 -emit-obj -w -fexceptions -fcxx-exceptions -gline-tables-only -O2 -std=gnu++11

Thanks for the revert!

mentioned in issue llvm/llvm-bugzilla-archive#22114