Re: [Ask for help]: Met a problem with strtof

[Wang Weidong <wangweidong1 at huawei dot com>]

On 2014/4/25 22:26, Ryan Arnold wrote:
> Hi Mark & Wang,
> 
> I believe that between glibc 2.16 and glibc 2.19 there was a focus on
> improving the conformance of the FP routines w/rt rounding modes and
> conforming error conditions to the various specifications.  Joseph
> Myers was working on that.
>
> Ryan
>

OK, Thanks. Is "joseph@codesourcery.com" ?
 
> On Fri, Apr 25, 2014 at 9:18 AM, Mark Brown <ms_brown@sbcglobal.net> wrote:
>> On 04/25/2014 02:34 AM, Wang Weidong wrote:
>>> I found a Bug report on https://sourceware.org/bugzilla/show_bug.cgi?id=14518
>>> which report "strtod ignores the rounding mode and always tries to round to nearest. "
>>> Such as FE_UPWARD is "rounding towards positive infinity"
>>> It means that the value should "<=" the rounding value.
>>> So I think in glibc-2.11 here "-0x1.4EF009P-16 -> -0x1.4ef00ap-16" it is wrong while
>>> in glibc-2.17+ is right. And similar to the others.
>>
>> Well, as I noted when I started this I'm not an FP expert; but the glibc
>> 2.19 results I get match my expectations.
>>

I use a binary models  "b32/ > +1.4EF009P-21 -1.000000P-5 -> -1.4EF009P-16".
This mode is from IBM FP-test-suit. We can download from

https://www.research.ibm.com/haifa/projects/verification/fpgen/ieeets.html

The syntax: Within FE_UPWARD mode, the operands is 32bits , do 
`+0x1.4EF009P-21/-0x1.000000P-5`, the expect result is '-0x1.4EF009P-16'.

But I test this with below code:
-------------------------------------------------
#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <fenv.h>

int main() {
	float f1,f2,f3,f4;
	fesetround(FE_UPWARD);
	f1 = strtof("+0x1.4EF009P-21", NULL);
	f2 = strtof("-0x1.000000P-5", NULL);
	f3 = f1/f2;
	f4 = strtof("-0x1.4EF009P-16", NULL);
	printf("%a == %a\n", f3, f4);
	assert (f3 == f4);

	return 0;
}

gcc -std=c99 -lm test.c -o test
./test`
--------------------------------------------------

On my fedora OS(glibc-2.17 gcc-4.8.2) it do Abort,
while on suse(glibc-2.11 gcc-4.3.2) it doesn't.
the result:
--------------------------------------------------
fedora: -0x1.4ef00ap-16 == -0x1.4ef008p-16
suse:   -0x1.4ef00ap-16 == -0x1.4ef00ap-16
--------------------------------------------------

Is my code wrong? If so, how can I test it?

As I note that the test suite is "supporting only part of the features
of the IEEE 754R standard. " Maybe these binary models didn't update.

Regards
Wang

>> --
>> Mark Brown
>> ms_brown@sbcglobal.net
> 
> 
>