https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #18 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (In reply to George Pee from comment #17) > Any idea on why the issue is intermittent? For SMP not really, because I think that path doesn't use lazy context switching; but perhaps the kernel is smart enough to switch into non-SMP mode if only one processor is present at boot time (thus saving a lot of kernel locking). The kernel can disable the FPU at times (the most common case is a context switch) and then re-enable it when another VFP/SIMD instruction is encountered. If the first instruction encountered after it has been disabled is a FP16 operation, then the kernel fails to recognize it as such and so doesn't try to re-enable the VFP unit. If it's some other, recognized, operation then the unit gets re-enabled and then the fp16 instructions never take a fault. Lazy context switching can save time and energy loading/saving the VFP register state (which is relatively large) if most applications on the system use little or no FP/SIMD, but it's significantly more complicated on SMP systems because it means the state may have to be fetched from a different CPU's FPU if the process is switched to another CPU, so this is normally only done on single processor systems.
