search for: fmfs

Yes, you’re probably right about this. I was originally thinking of FENV_ACCESS as a fully strict mode of operation, but what you’re suggesting aligns with what Cameron suggested and even some of my own reasoning on other points. So, let me amend my previous proposal to say: STDC FENV_ACCESS {ON|OFF} Patch in progress. I think ON should force the following: except_behavior { strict }

...n the fast mode off with the pragma, but then not be >>> able to turn it back on ;) >>> >>> So, yes, except that I'm somewhat hesitant to invade the 'STDC' >>> space with vendor extensions. If we generally introduce a pragma to >>> control FMFs, maybe we should just use that instead? I don't have a >>> clear idea on the syntax, but for example, if we had some pragma >>> that let us do >>> >>> #pragma clang fast_math or #pragma clang fast_math nnan(off) >>> contract(on) or whatever then w...

...n we'd be able to turn the fast mode off with the pragma, but then not be able to turn it back on ;) >>>>> >>>>> So, yes, except that I'm somewhat hesitant to invade the 'STDC' space with vendor extensions. If we generally introduce a pragma to control FMFs, maybe we should just use that instead? I don't have a clear idea on the syntax, but for example, if we had some pragma that let us do >>>>> >>>>> #pragma clang fast_math or #pragma clang fast_math nnan(off) contract(on) or whatever then we could use that. What do...

...9;t add something like this, then we'd be able to turn the fast mode off with the pragma, but then not be able to turn it back on ;) > > So, yes, except that I'm somewhat hesitant to invade the 'STDC' space with vendor extensions. If we generally introduce a pragma to control FMFs, maybe we should just use that instead? I don't have a clear idea on the syntax, but for example, if we had some pragma that let us do > > #pragma clang fast_math or #pragma clang fast_math nnan(off) contract(on) or whatever then we could use that. What do you think? That looks great; i...

> On Mar 15, 2017, at 2:00 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On 03/15/2017 01:47 PM, Adam Nemet wrote: >> >>> On Mar 15, 2017, at 11:36 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>> >>> >>>> On Mar 15, 2017, at 10:13 AM, Hal Finkel via cfe-dev <cfe-dev at

On Fri, Jan 17, 2020 at 8:09 PM Finkel, Hal J. <hfinkel at anl.gov> wrote: > Andy, thanks for writing this up. A few thoughts: > > 1. The mental model that I have is that there is always an FP_CONTRACT pragma: there's some default (implicit) pragma at the beginning, and what it says (off/on/fast) is controlled by the command-line flags (or the driver's default if no flags

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set