issue 7006 - std.math.pow (integral, integral) crashes on negative exponents

[Timon Gehr]

On 18.12.19 03:58, Timon Gehr wrote:
> On 18.12.19 03:44, Timon Gehr wrote:
>> On 18.12.19 03:30, Timon Gehr wrote:
>>> On 18.12.19 03:14, Timon Gehr wrote:
>>>>
>>>> Perhaps what you mean to say is that the C++ standard is understood 
>>>> to be so lax that it doesn't actually define the expected result of 
>>>> pow for anything but the listed special cases, such that 
>>>> pedantically speaking, pow could return NaN (or, usually, any other 
>>>> value) for all other pairs of arguments (usually, without raising a 
>>>> domain error)?
>>>
>>> Reviewing this page, this does not appear to be the case either:
>>> https://en.cppreference.com/w/cpp/numeric/fenv/FE_round
>>>
>>> So I guess I still don't understand why you think an implementation 
>>> could return an arbitrary value.
>>
>> The following simple test that would have been able to refute my 
>> interpretation of the standard failed to do so:
>>
>> ...

Ok, I found a case where glibc++ computes a wrong result:

#include <cmath>
#include <cfenv>
#include <iostream>
using namespace std;

int main(){
     #pragma STDC FENV_ACCESS ON
     double x=193513.887169782;
     double y=44414.97148164646;
     fesetround(FE_DOWNWARD);
     double r1=atan2(y,x);
     fesetround(FE_UPWARD);
     double r2=atan2(y,x);
     cout<<*(unsigned long long*)&r1<<endl; // 4597296506280443981
     cout<<*(unsigned long long*)&r2<<endl; // 4597296506280443981
}

If I use `long double` instead for intermediate calculations, the upper 
bound is the correct 4597296506280443982. So I guess the C++ standard 
(like IEEE floating point) does not require exact rounding for some 
transcendental functions, most likely including pow. Unfortunately, I 
haven't found any details about precision requirements for C++ floating 
point library functions using a cursory Google search, so it may indeed 
be the case that there are absolutely none. Do you have any source that 
says as much?