On Fri, May 26, 2017 at 12:39 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Fri, 26 May 2017, Richard Biener wrote: > >> On Fri, May 26, 2017 at 11:52 AM, Marc Glisse <marc.gli...@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.
Also with -fnon-call-exceptions? >> But it may be pure. > > > It writes to the exception register (aka memory for now), so I would hardly > call it pure. But it doesn't have to be ordered with control word writes/reads, no? >> Likewise fetestexcept may be pure? > > > Too unsafe for now, since any FP operation can write to the memory that > fetestexcept reads. Ah... but then FP operations are not ordered with the builtins anyway, only FP loads/stores would be. After all having builtins is only the first easiest step of properly modeling dependences between FP ops and the FP control/exception registers. Richard. > > -- > Marc Glisse
