search for: fegetround

...tion defined. In clang the default state will be off. The C99 standard states that accessing the FP environment (testing FP status flags, changing FP control modes, etc.) when FENV_ACCESS is off is undefined behavior. The C99 standard provides library calls to access the environment (fesetround, fegetround, fetestexcept, etc.) but you can only safely use these if you have set FENV_ACCESS to the "on" state. A typical usage might look like this: #include <fenv.h> double someFunc(double A, double B, bool ForceRoundUp) { #pragma STDC FENV_ACCESS ON double Result; if (ForceRoundUp...

...state will be off. The C99 standard states that accessing > the FP environment (testing FP status flags, changing FP control > modes, etc.) when FENV_ACCESS is off is undefined behavior. The > C99 standard provides library calls to access the environment > (fesetround, fegetround, fetestexcept, etc.) but you can only > safely use these if you have set FENV_ACCESS to the “on” state. A > typical usage might look like this: > > #include <fenv.h> > > double someFunc(double A, double B, bool ForceRoundUp) { > > #pragma STDC FE...

...d above, I think front ends should define clear circumstances under which such changes are permitted, but the mechanism for making such changes is independent of the constrained FP intrinsics. For example, consider the following C function. double foo(double A, double B, double C) { int OrigRM = fegetround(); fesetround(FE_TOWARDZERO); double tmp = A + B; fesetround(OrigRM); return tmp + C; } Assuming the compiler was in a state where it knew fenv access was enabled, I would expect that to get translated to something like this (after SROA cleanup): define double @foo(double %A, double %B, d...

...=-= double doSomethingVague(double X, double Y, double Z) { // Some operation that doesn't need to be precise. if (X/Y > SomeThreshold) return doSomethingPrecise(X, Y); else return Z; } #pragma STDC FENV_ACCESS ON double doSomethingPrecise(double X, double Y) { int SaveRM = fegetround(); fesetround(FE_DOWNWARD); feclearexcept(FE_ALL_EXCEPT); double Temp = X * Y + Z; if (fetestexcept(FE_ALL_EXCEPT)) std::cerr << "Something happened.\n"; fesetround(SaveRM); return Temp; } -=-=-=-=-=-=-=-= Now suppose I compile that with "-O2 -ffp-contract=fas...

Let me clarify. These aren’t intended to be exposed to the user. The user code that leads to the generation of these intrinsics will be normal floating point operations combined with either pragmas (such as “STDC FENV_ACCESS ON”) or command line options (such as the recently introduced “-fp-model=strict”). The reason I’ve been avoiding normal constant values is that it provides no information when

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