search for: __flt_rounds

Peter, Could you please comment on: http://llvm.org/bugs/show_bug.cgi?id=12757 Specifically, gcc seems to allow this: int __flt_rounds() { unsigned long fpscr; __asm__ volatile("mffs %0" : "=f"(fpscr)); return fpscr; } My reading of this is that gcc allocates a floating-point register to hold the result of the mffs instruction, and then bit casts (and truncates?) the result into the unsigned long variable....

...culative execution) while still allowing it to optimize away potential exceptions (e.g. dce operations whose results are never used). > FLT_ROUNDS, FLT_EVAL_METHOD and math_errhandling are controlled by the c runtime, so a compiler has no business changing them, the compiler can define its own __FLT_ROUNDS, etc macros and the libc may or may not use those, but e.g. in case of FLT_ROUNDS it makes no sense for the compiler to try to do anything: the mode changes at runtime, the libc macro will expand to a function call that determines the current rounding mode. (same problem arises if you can change th...

On Fri, 2012-04-27 at 14:54 -0500, Hal Finkel wrote: > There is a comment in the file which reads: > > /* The weird 'i#*X' constraints on the following suppress a gcc > warning when __excepts is not a constant. Otherwise, they mean the > same as just plain 'i'. */ [sinp] > ("mtfsb0 %s0" : : "i#*X"(__builtin_ffs (__excepts))); [snip]

Hello, I am not sure whether this is a clang issue, an LLVM issue, or both; but clang chokes when parsing expanded macros from the glibc /usr/include/bits/fenvinline.h with an error like: ./boost/math/tools/config.hpp:279:10: error: invalid input constraint 'i#*X' in asm feclearexcept(FE_ALL_EXCEPT); ^ /usr/include/bits/fenvinline.h:56:11: note: expanded from macro

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

...setting of > support_math_errno. Should MATH_ERREXCEPT be set or cleared based on > except_behavior? > > > FLT_ROUNDS, FLT_EVAL_METHOD and math_errhandling > > are controlled by the c runtime, so a compiler has no business changing them, > the compiler can define its own __FLT_ROUNDS, etc macros and the libc may or > may not use those, but e.g. > in case of FLT_ROUNDS it makes no sense for the compiler to try to do anything: > the mode changes at runtime, the libc macro will expand to a function call that > determines the current rounding mode. (same problem arises...