In fact, after looking at the latest gcc-patches messages, I think it may be
due to this commit: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01107.html
(based purely on the fact that the unrecognized insn is a call, and the patch
deals with CALL_EXPR).
FX
> I am testing trunk on darwin14 (Mac OS X Yosemite), and I am seeing a lot of
> (800 so far) C++ failures, in the form of internal compiler errors, like this:
>
>> vbase1.C:17:1: error: unrecognizable insn:
>> }
>> ^
>> (call_insn/j 4 3 5 (call (mem/u/c:DI (const:DI (unspec:DI [
>> (symbol_ref/i:DI ("_ZN8VDerivedD1Ev") [flags 0x1]
>> <function_decl 0x143563d80 __comp_dtor >)
>> ] UNSPEC_GOTPCREL)) [0 S8 A8])
>> (const_int 0 [0])) vbase1.C:9 -1
>> (nil)
>> (nil))
>> vbase1.C:17:1: internal compiler error: in insn_default_length, at
>> config/i386/i386.md:2071
>
>
> Google and bugzilla search don’t find anything particularly recent like that,
> but the scale of it is weird. I have isolated a very small reproducer,
> attached (gives the above ICE with no compile options).
>
> Has anyone seen this on another platform? Is it known? Otherwise, I’ll report
> it.
>
> FX
>
>
>
> <vbase1.C>
