I haven't tested it myself yet, but looking at the blame list in the bot, r200383 looks like the only change that can break the world this way. There aren't ASSERTIONS in the crash logs, so my guess is that this has to do with system malloc, because tests work in the release bot.
Tried a release build with system malloc, and tests didn't crash, so next one to blame was the compiler. Tried a debug build with clang and tests didn't crash either, so it seems to be another GCC problem...
$ g++ --version
g++ (Debian 4.9.2-10) 4.9.2
(In reply to comment #1)
> $ g++ --version
> g++ (Debian 4.9.2-10) 4.9.2
4.9 is the same version that the bots run.
I wonder if this is also reproducible with GCC 5 or GCC 6
Ii looks like r200383 also broke the Windows debug bot:
The callFunc functions that are instantiated must be aligned to the minimum supported value so that the two tags can be encoded into the bottom two bits of the pointer value.
This isn't the case in builds with GCC that don't at least use -O2 -- -falign-functions is disabled then, and callFunc address can have the second-lowest bit always set. Lazy initialization in callFunc<>() then fails because the pointer value always seems to encode the initialization tag, returning early and not initializing anything.
The simplest way to deal with this would be to slap a aligned() attribute onto the static function declaration.
Only tested on x86-64. ARM Thumb2 probably suffers from the same issue, but AFAIU this is occurring even in release builds where -falign-functions should be enabled.
*** This bug has been marked as a duplicate of bug 157045 ***