public inbox for
 help / color / mirror / Atom feed
From: Marc Glisse <>
To: Richard Biener <>
Cc: GCC Patches <>
Subject: Re: builtin fenv functions
Date: Sun, 28 May 2017 22:26:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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",
>>> 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.

>>> 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.

>>> 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...

Marc Glisse

  reply	other threads:[~2017-05-28 22:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 10:27 Marc Glisse
2017-05-26 10:39 ` Richard Biener
2017-05-26 10:49   ` Marc Glisse
2017-05-26 10:58     ` Richard Biener
2017-05-28 22:26       ` Marc Glisse [this message]
2017-05-29  8:46         ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).