Re: builtin fenv functions

[Marc Glisse <marc dot glisse at inria dot fr>]

On Fri, 26 May 2017, Richard Biener wrote:

> On Fri, May 26, 2017 at 11:52 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> > Hello,
> >
> > coming back to https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01378.html ,
> > Richard wanted a complete set of fenv functions instead of just the 2 I was
> > interested in. However, most functions in fenv.h handle a struch fenv_t or
> > fexcept_t, which makes them inconvenient to handle as builtins.
>
> We do have stdio functions having FILE * arguments.  There's 'fileptr_type_node'
> (pointer to incomplete struct) to handle that.  I suppose rth was looking for
> sth similar for fenv_t * and fexcept_t *.  I guess it's hard to implement a
> dependency scheme other than "memory" without seeing the full set of
> functions.

I'll see how hard it is to imitate FILE*...

> > Similarly, I
> > don't see div as a builtin in that file, only FILE* has special code, but
> > that doesn't seem worth the trouble here. So I am only declaring the 5
> > "simple" functions, with minimal properties: leaf, nothrow, and for
> > fegetround pure (glibc already declares it that way). We can then discuss
> > the safety of future optimizations on a case by case basis.
>
> +DEF_C99_BUILTIN        (BUILT_IN_FERAISEEXCEPT, "feraiseexcept",
> BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
>
> I think feraiseexcept shouldn't be nothrow?

glibc marks it as nothrow. I can remove the nothrow flag for now, for 
safety. It may trap, but it does not throw a C++ exception AFAIU.

> But it may be pure?

It writes to the exception register (aka memory for now), so I would 
hardly call it pure.

> Likewise fetestexcept may be pure?

Too unsafe for now, since any FP operation can write to the memory that 
fetestexcept reads.

--
Marc Glisse