Make ARM fesetenv (FE_NOMASK_ENV) detect failure (bug 14866)

Make ARM fesetenv (FE_NOMASK_ENV) detect failure (bug 14866)

[Joseph S. Myers]

As discussed in the thread starting at
<http://sourceware.org/ml/libc-ports/2012-06/msg00021.html>, ARM VFPv3
and VFPv4 do not support trapping floating-point exceptions, and
fesetenv (FE_NOMASK_ENV) should return nonzero (failure) in such a
case, but does not do so, and as suggested by Richard Henderson and
detailed in
<http://sourceware.org/ml/libc-ports/2012-06/msg00091.html>, this can
be achieved by reading back the relevant bits and seeing if they were
successfully set.  I've applied this patch (tested for both VFPv2 and
VFPv3) to fix this issue in that way.

2012-11-21  Joseph Myers  <joseph@codesourcery.com>

	[BZ #14866]
	* sysdeps/arm/fesetenv.c (__fesetenv): Test whether bits for
	trapping exceptions were successfully set for FE_NOMASK_ENV.

diff --git a/ports/sysdeps/arm/fesetenv.c b/ports/sysdeps/arm/fesetenv.c
index 2fad61d..e92f9f5 100644
--- a/ports/sysdeps/arm/fesetenv.c
+++ b/ports/sysdeps/arm/fesetenv.c
@@ -40,6 +40,16 @@ __fesetenv (const fenv_t *envp)
 
       _FPU_SETCW (temp);
 
+      if (envp == FE_NOMASK_ENV)
+	{
+	  /* VFPv3 and VFPv4 do not support trapping exceptions, so
+	     test whether the relevant bits were set and fail if
+	     not.  */
+	  _FPU_GETCW (temp);
+	  if ((temp & _FPU_IEEE) != _FPU_IEEE)
+	    return 1;
+	}
+
       /* Success.  */
       return 0;
     }

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Make ARM fesetenv (FE_NOMASK_ENV) detect failure (bug 14866)

[Richard Henderson]

On 11/21/2012 12:28 PM, Joseph S. Myers wrote:
> +      if (envp == FE_NOMASK_ENV)
> +	{
> +	  /* VFPv3 and VFPv4 do not support trapping exceptions, so
> +	     test whether the relevant bits were set and fail if
> +	     not.  */
> +	  _FPU_GETCW (temp);
> +	  if ((temp & _FPU_IEEE) != _FPU_IEEE)
> +	    return 1;
> +	}

Why test vs FE_NOMASK_ENV explicitly?  In theory the exception value
could have come from just about anywhere.

This would seem to do the same thing with fewer assumptions:

  if (temp & _FPU_IEEE)
    {
      unsigned temp2;
      _FPU_GETCW (temp2);
      if (temp != temp2)
        return 1;
    }


r~

Re: Make ARM fesetenv (FE_NOMASK_ENV) detect failure (bug 14866)

[Joseph S. Myers]

On Wed, 21 Nov 2012, Richard Henderson wrote:

> On 11/21/2012 12:28 PM, Joseph S. Myers wrote:
> > +      if (envp == FE_NOMASK_ENV)
> > +	{
> > +	  /* VFPv3 and VFPv4 do not support trapping exceptions, so
> > +	     test whether the relevant bits were set and fail if
> > +	     not.  */
> > +	  _FPU_GETCW (temp);
> > +	  if ((temp & _FPU_IEEE) != _FPU_IEEE)
> > +	    return 1;
> > +	}
> 
> Why test vs FE_NOMASK_ENV explicitly?  In theory the exception value
> could have come from just about anywhere.

The fesetenv argument must either be one of the macros from fenv.h, or an 
environment previously obtained from one of the fenv.h functions in the 
same execution of the same program (and in the latter case, if these bits 
are set it means the processor supports them).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Make ARM fesetenv (FE_NOMASK_ENV) detect failure (bug 14866)

[Richard Henderson]

On 11/21/2012 02:08 PM, Joseph S. Myers wrote:
> On Wed, 21 Nov 2012, Richard Henderson wrote:
> 
>> On 11/21/2012 12:28 PM, Joseph S. Myers wrote:
>>> +      if (envp == FE_NOMASK_ENV)
>>> +	{
>>> +	  /* VFPv3 and VFPv4 do not support trapping exceptions, so
>>> +	     test whether the relevant bits were set and fail if
>>> +	     not.  */
>>> +	  _FPU_GETCW (temp);
>>> +	  if ((temp & _FPU_IEEE) != _FPU_IEEE)
>>> +	    return 1;
>>> +	}
>>
>> Why test vs FE_NOMASK_ENV explicitly?  In theory the exception value
>> could have come from just about anywhere.
> 
> The fesetenv argument must either be one of the macros from fenv.h, or an 
> environment previously obtained from one of the fenv.h functions in the 
> same execution of the same program (and in the latter case, if these bits 
> are set it means the processor supports them).
> 

Yeah, but the fine point of "same execution same program" could easily be
missed.  I was thinking of a distributed system containing a mix of VFPv2/v3
processors, in which fenv_t values were shared across nodes.

Not so very likely, but why not program more robustly?  Especially if, as I
suspect, the more robust formulation actually results in fewer insns?


r~