Created attachment 13629 [details]
repro

"D:\\src\\llvm-ninja-rel64\\bin\\clang-cl.exe" "-cc1" "-triple" "i386-pc-windows-msvc" "-emit-obj" "-disable-free" "-main-file-name" "quic_crypto_server_config_test.cc" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-relaxed-aliasing" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-target-cpu" "pentium4" "--dependent-lib=libcmt" "--dependent-lib=oldnames" "-fno-rtti-data" "-fdiagnostics-format" "msvc-fallback" "-gline-tables-only" "-dwarf-column-info" "-ffunction-sections" "-fdata-sections" "-coverage-file" "D:\\src\\chromefetch\\src\\out\\Release\\quic_crypto_server_config_test.cc" "-resource-dir" "D:\\src\\llvm-ninja-rel64\\bin\\..\\lib\\clang\\3.6.0" "-internal-isystem" "D:\\src\\llvm-ninja-rel64\\bin\\..\\lib\\clang\\3.6.0\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\include" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\8.1\\include\\shared" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\8.1\\include\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\8.1\\include\\winrt" "-O2" "-std=c++11" "-fdeprecated-macro" "-fdebug-compilation-dir" "D:\\src\\chromefetch\\src\\out\\Release" "-ferror-limit" "19" "-fmessage-length" "135" "-mstackrealign" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=18.0" "-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" "-vectorize-slp" "-o" "obj\\net\\quic\\crypto\\net_unittests.quic_crypto_server_config_test.obj" "-x" "c++" -w foo.ii

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 :-)

Created attachment 13635 [details]
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

Created attachment 13638 [details]
Simpler test case

(In reply to comment #5)
> Created attachment 13638 [details]
> Simpler test case

Build with -O2 -g for this one.

Created attachment 13639 [details]
reduced.cc

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

Created attachment 13640 [details]
reduced.cc

Now occurs without optimizations.

normal c++ program, no objective-c blocks or nothin', no optimizations needed to trigger:
template <class> struct c {
  c();
  template <class U> __attribute__((__always_inline__)) c(c<U>) {}
};
struct {
  c<double> v = c<int>();
} o;

*** Bug 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 = "<primary>";
  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

(In reply to comment #15)
> 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 <typename> struct B {
  static Class *m_theClass;
  void m_fn1() { B<int>::m_theClass; }
};

template <typename T>
Class *B<T>::m_theClass = new Class(0);

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

Thanks for the revert!