Imho a pure overload solution is not tenable. By the time you get to fma you're looking at 729 overloads. <cmath> becomes so huge it is expensive just to include it. Either we find a working solution that doesn't involve 729 fma overloads, or we petition the committee on the grounds that the spec is not reasonably implementable.
Howard On Dec 19, 2013, at 4:21 PM, Matt Calabrese <[email protected]> wrote: > This still technically behaves differently from what the standard > specifies. One example is that since the parameters in question are > taken by value, the argument that is convertible to the arithmetic > type must be movable and/or copyable (depending on context), otherwise > the function won't be able to be called (and in the case where the > type is copyable or movable, you are intruding a [potentially > non-trivial] copy/move operation that shouldn't be happening). The > actual specified version would just work. The parameter could be taken > by r-value reference and things could be slightly adjusted to have > this type of case work, but there will still be other subtle problems, > such as the signature change. > > Ultimately, I think it's best to just follow the standard exactly to > avoid subtleties like this. It might be best to just stamp out the > overloads with the preprocessor either through individual macro > invocations or via an inclusion trick, probably preferring the latter > over the former. To elaborate on that, you could include the same file > internally, multiple times, but each time with a different arithmetic > type specified as the redefinition of a macro used by the > implementation: > > #define __CURRENT_CMATH_TYPE float > #include <some_underlying_implementation_file> > #undef __CURRENT_CMATH_TYPE > #define __CURRENT_CMATH_TYPE double > #include <some_underlying_implementation_file> > // etc. > > It's hairy, but at least you're guaranteed to not stray from specified > behavior and you're still removing redundancy. > > On Thu, Dec 19, 2013 at 9:26 AM, Marshall Clow <[email protected]> wrote: >> http://llvm.org/bugs/show_bug.cgi?id=18218 >> >> This turned out not to be a problem with isnan, but rather a pervasive >> pattern encompassing all of the functions in <cmath> >> >> The patch is very large, but is really just the same bug fix applied to: >> abs, acos asin, atan, atan2, ceil, cos, cosh, exp, fabs, floor, fmod, >> frexp, ldexp, log, log10, modf, pow, sin, sinh, sqrt, tan, tanh, signbit, >> fpclassify, isfinite, isinf, isnan, isnormal, isgreater, isgreaterequal, >> isless, islessequal, islessgreater, isunordered, acosh, asinh, atanh, cbrt, >> copysign, erf, erfc, exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb, >> lgamma, llrint, llround, log1p, log2, logb, lrint, lround, nearbyint, >> nextafter, nexttoward, remainder, remquo, rint, round, scalbln, scalbn, >> tgamma, trunc >> >> -- Marshall >> >> Marshall Clow Idio Software <mailto:[email protected]> >> >> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is >> promptly moderated down to (-1, Flamebait). >> -- Yu Suzuki >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > > > > -- > -Matt Calabrese _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
