On Mon, May 29, 2017 at 12:09 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Fri, 26 May 2017, Richard Biener wrote: > >>>>> 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? > > > Hmm, maybe on windows where trap handlers turn into system exceptions which > are handled like C++ exceptions... I am happy to remove nothrow.
Ok. I suppose as glibc has it nothrow differing is somewhat pointless as as soon as someone includes the fenv.h header it'll get overridden. >>>> 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? > > > Not sure what you mean here. feraiseexcept(FE_DIVBYZERO) is equivalent to > 1./0., it writes to the exception status flag. Its order with respect to > fetestexcept must be preserved. I see. >>>> 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. > > > Since gcc doesn't handle fenv properly, people have been using a number of > workarounds, in particular with pass-through asm, sometimes volatile, > occasionally with the "memory" clobber. > > Some of those versions would still work with pure, but the attribute > increases the likelyhood of breaking some of those uses, and I don't know if > it would ever help in practice, so I would rather not add it for now. > fegetround is very different since it can safely swap position with an > adjacent float operation. > >> After all having builtins is only the first easiest step of properly >> modeling >> dependences between FP ops and the FP control/exception registers. > > > Yes, I didn't expect adding those 5 builtins (modulo the nothrow flag) to be > controversial... Surely not. I'm fine with erring on the conservative side for now. Thanks, Richard. > -- > Marc Glisse
