With that patch applied my 32-bit libclang.dll built with mingw does not crash anymore
unit tests are not affected by that change
From the bug, this is related to Richard's "r289413 - Add two new AST nodes to represent initialization of an array in terms of initialization of each array element", which broke MSVC builds due to under-alignment, which Reid addressed with "r289575 - Align EvalInfo in ExprConstant to avoid PointerUnion assertions".
Perhaps there's a problem with MinGW 4.9.2's alignas? Or is this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936 as Reid says in https://bugs.llvm.org/show_bug.cgi?id=32018#c8 ?
The same alignment in other places works fine. i don't know the source of that issue. Should be somewhere in gcc(mingw) but it's not my focus.
So this is a workaround that we can make (probably only for mingw builds)
@rnk isn't this related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936
Assuming this is in fact a gcc bug this will most likely cause a regression with the standalone clang mingw toolchains we are on the verge of having.
This is of course assuming clang does not have the same regression gcc does.
I looked at the blame, and I added this alignment thing in rL289575 to deal with some PointerIntPair assertions. Those probably started in @gbiv's rL270781, which introduced a PointerIntPair<EvalInfo*,1,bool> field. I think we can just fix this problem by not being so clever. We can unpack the boolean and the pointer, and everything will work fine.
It's possible, but nobody has debugged any of these crashes and shown the same ret $imm inconsistencies that I was pointing out in that bug. This seems unrelated at first.