Patch: bug fix for PR18218

[Howard Hinnant]

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 <rivorus at gmail.com> 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 <mclow.lists at gmail.com> 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:mclow.lists at gmail.com>
>> 
>> 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
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>> 
> 
> 
> 
> -- 
> -Matt Calabrese