search for: isnormal

...magnitude greater than or equal to a minimum bemin value, where b is the radix. Normal numbers can use the full precision available in a format. In this standard, zero is neither normal nor subnormal. This implies that a denormal is not a normal number. In contrast, the current implementation of isNormal in APFloat does treat denormal numbers as normal numbers breaking this definition. This is not just a predicate that has a name that differs from IEEE-754R (which I am fine with), but is an actual name collision with IEEE-754R with a different semantic meaning. This could easily lead to programmer...

...an or equal to a minimum bemin value, where b is the radix. Normal numbers can use the full precision available in a format. In this standard, zero is neither normal nor subnormal. > > This implies that a denormal is not a normal number. > > In contrast, the current implementation of isNormal in APFloat does treat denormal numbers as normal numbers breaking this definition. This is not just a predicate that has a name that differs from IEEE-754R (which I am fine with), but is an actual name collision with IEEE-754R with a different semantic meaning. This could easily lead to programmer...

...to a minimum > bemin value, where b is the radix. Normal numbers can use the full precision > available in a format. In this standard, zero is neither normal nor > subnormal. > > This implies that a denormal is not a normal number. > > In contrast, the current implementation of isNormal in APFloat does treat > denormal numbers as normal numbers breaking this definition. This is not > just a predicate that has a name that differs from IEEE-754R (which I am > fine with), but is an actual name collision with IEEE-754R with a different > semantic meaning. This could easily...

...lue, where b is the radix. Normal numbers can use the full precision >> available in a format. In this standard, zero is neither normal nor >> subnormal. >> >> This implies that a denormal is not a normal number. >> >> In contrast, the current implementation of isNormal in APFloat does treat >> denormal numbers as normal numbers breaking this definition. This is not >> just a predicate that has a name that differs from IEEE-754R (which I am >> fine with), but is an actual name collision with IEEE-754R with a different >> semantic meaning. T...

...fs. + // If it's not a floating point number then it must be 'fast'. + return !isa<ConstantFP>(MD->getOperand(0)); Here as well. + if (ConstantFP *CFP0 = dyn_cast_or_null<ConstantFP>(Op0)) { + APFloat Accuracy = CFP0->getValueAPF(); + Assert1(Accuracy.isNormal() && !Accuracy.isNegative(), + "fpmath accuracy not a positive number!", &I); To be pedantic for a moment, zero is not a positive number. What about asserting these individually to give us more clear asserts if they fire? That also makes the string easier to writ...

...ting point number then it must be 'fast'. > + return !isa<ConstantFP>(MD->getOperand(0)); > > Here as well. > > + if (ConstantFP *CFP0 = dyn_cast_or_null<ConstantFP>(Op0)) { > + APFloat Accuracy = CFP0->getValueAPF(); > + Assert1(Accuracy.isNormal() && !Accuracy.isNegative(), > + "fpmath accuracy not a positive number!", &I); > > To be pedantic for a moment, zero is not a positive number. Zero is not allowed. The isNormal call will return false for zero. What about asserting > these individually to give...

...nclude/cmath:311:9: error: '::fpclassify' has not been declared using ::fpclassify; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:312:9: error: '::isfinite' has not been declared using ::isfinite; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:315:9: error: '::isnormal' has not been declared using ::isnormal; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:316:9: error: '::isgreater' has not been declared using ::isgreater; ^ llvm-3.8.0.src/projects/libcxx/include/cmath:317:9: error: '::isgreaterequal' has not been declared us...

Greetings! I have been building llvm-3.6.x, 3.7.1 and 3.7.2 with (glibc-2.12.1, binutils-2.24, gcc-4.9.2) almost same set if CMake flags. However while building LLVM-3.8.0 using same CMake flags I am observing projects/libcxx/include/cmath errors... ...'::signbit' has not been declared ...'::fpclassify' has not been declared ...'::isfinite' has not been declared ...

Here's a revised patch, plus patches showing how fpmath metadata could be turned on in clang and dragonegg (it seemed safest for the moment to condition on -ffast-math rather than on one of the flags implied by -ffast-math). Major changes: - The FPMathOperator class can no longer be used to change math settings, only to read them. Currently it can be queried for accuracy info. I split the

The attached patch is a first attempt at representing "-ffast-math" at the IR level, in fact on individual floating point instructions (fadd, fsub etc). It is done using metadata. We already have a "fpmath" metadata type which can be used to signal that reduced precision is OK for a floating point operation, eg %z = fmul float %x, %y, !fpmath !0 ... !0 = metadata