[libcxx+newlib] nexttoward{f,l,} shims for _LDBL_EQ_DBL systems

[Craig Howland]

(Sorry, I was out for a bit and am just starting to catch up on this thread.)
On 12/09/2014 06:36 PM, Jeff Johnston wrote:
> ----- Original Message -----
>> From: "Jonathan Roelofs" <jonathan@codesourcery.com>
>> To: "Jeff Johnston" <jjohnstn@redhat.com>
>> Cc: "JF Bastien" <jfb@chromium.org>, "Craig Howland" <howland@lgsinnovations.com>, newlib@sourceware.org
>> Sent: Tuesday, December 9, 2014 5:38:40 PM
>> Subject: Re: [libcxx+newlib] nexttoward{f,l,} shims for _LDBL_EQ_DBL systems
>>
>>
>>
>> On 12/9/14 3:15 PM, Jeff Johnston wrote:
>> ... 
>>> 2. You have put the nexttowardf function prototype in the math.h section
>>> where
>>> _LDBL_EQ_DOUBLE is true but the code itself doesn't use the flag as
>>> it doesn't rely on long double internals.
>> Oh, right. Good point. I'll take it out of _LDBL_EQ_DOUBLE.
Actually, it probably strictly does belong in the _LDBL_EQ_DOUBLE section, as it 
uses isnan().  isnan(), in turn, calls __fpclassify(), which only will work 100% 
properly when ldbl==double (i.e., it does not work for all inputs when 
ldbl>double).  I suppose that for the restricted case of fpclassify() being used 
for isnan(), it should work OK when ldbl>double, as the compiler would convert 
the NAN properly to double for the __fpclassifyd() call.  But doing this would 
be a dangerous precedent, implying that fpclassify was OK with unrestricted long 
double.  Thoughts, Jeff?
Craig