target/loongarch: check FPE before reading fcc in bceqz/bcnez

gen_cz_bc() loads env->cf[cj] without CHECK_FPE, unlike every other translator that touches an fcc register (trans_fcmp.c.inc and trans_fmov.c.inc, for movcf2gr/movgr2cf/movcf2fr/movfr2cf/fsel). A guest that manages the FPU lazily -- Linux clears CSR.EUEN.FPE in lose_fpu() on every context switch -- relies on the next fcc access raising a Floating-Point-Disabled exception so the kernel can restore that task's fcc. Because bceqz and bcnez never raise it, they branch on the condition flag left behind by whichever task last owned the FPU. Real Loongson hardware does raise the exception, so this is TCG-only. It surfaces as Go binaries dying at startup in runtime.check() with "fatal error: float64nan1" -- roughly one process start in a thousand once the guest has more runnable tasks than vCPUs -- and in general as a conditional branch silently taking the wrong path. With four tasks each executing 5M bcnez on a 2-vCPU guest, master mispredicts 89 of 20000000. With this patch, 0 of 100000000 over five runs; a Loongson-3C5000 is likewise 0 of 600000000. CHECK_FPE is defined in trans_farith.c.inc, which translate.c includes before trans_branch.c.inc, so it is already in scope. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4209 Cc: qemu-stable@nongnu.org Signed-off-by: Jan Mercl <0xjnml@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20260819132422.5164-1-0xjnml@gmail.com> Signed-off-by: Song Gao <gaosong@loongson.cn>