From 335e5caa9a9e0f28acf94fe4c2871017fcd71794 Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Tue, 2 Jun 2015 21:43:54 +0200 Subject: score: Add Thread_Control::is_fp Store the floating-point unit property in the thread control block regardless of the CPU_HARDWARE_FP and CPU_SOFTWARE_FP settings. Make sure the floating-point unit is only enabled for the corresponding multilibs. This helps targets which have a volatile only floating point context like SPARC for example. --- c/src/lib/libcpu/powerpc/new-exceptions/cpu.c | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) (limited to 'c') diff --git a/c/src/lib/libcpu/powerpc/new-exceptions/cpu.c b/c/src/lib/libcpu/powerpc/new-exceptions/cpu.c index 0b0527ec4d..1e564f77e6 100644 --- a/c/src/lib/libcpu/powerpc/new-exceptions/cpu.c +++ b/c/src/lib/libcpu/powerpc/new-exceptions/cpu.c @@ -98,8 +98,6 @@ void _CPU_Context_Initialize( } #ifdef PPC_MULTILIB_FPU - msr_value |= MSR_FP; -#else /* * The FP bit of the MSR should only be enabled if this is a floating * point task. Unfortunately, the vfprintf_r routine in newlib @@ -108,21 +106,7 @@ void _CPU_Context_Initialize( * of vfprintf.c will be required to avoid this behavior. At this * time (7 July 1997), this restructuring is not being done. */ - - /* Make sure integer tasks have no FPU access in order to - * catch violations. Gcc may implicitely use the FPU and - * data corruption may happen. - * Since we set the_contex->msr using our current MSR, - * we must make sure MSR_FP is off if (!is_fp)... - * Unfortunately, this means that users of vfprintf_r have to use FP - * tasks or fix vfprintf. Furthermore, users of int-only tasks - * must prevent gcc from using the FPU (currently -msoft-float is the - * only way...) - */ - if ( is_fp ) - msr_value |= PPC_MSR_FP; - else - msr_value &= ~PPC_MSR_FP; + msr_value |= MSR_FP; #endif #ifdef PPC_MULTILIB_ALTIVEC -- cgit v1.2.3