Re: port-mips/57680: printf("%.1f") shows wrong resultsonR3000mipseb

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR port-mips/57680; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Cc: gnats-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-mips/57680: printf("%.1f") shows wrong resultsonR3000mipseb
Date: Mon, 6 Nov 2023 21:45:52 +0000

 > Date: Sun, 5 Nov 2023 17:01:44 +0900
 > From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
 > 
 > It looks these inline functions make gcc optimization confused,
 > but now I have one question:
 > 
 >   Is there any reason why we don't use -DTrust_FLT_ROUNDS that
 >   just uses __flt_round() in libc, rather hacked fegetround() in libm?
 >   (it looks most ports have flt_round in libc/arch/${MACHINE_CPU}/gen)
 
 This is a good question.  I think that should work, and it might be
 better than the fegetround weak reference.  But I would want to do
 some testing first.  I would also like to confirm that t_fenv, which
 now checks FLT_ROUNDS against fpgetround and fegetround, works on all
 architectures.
 
 It is a little concerning that we have so many copies of the same
 logic -- some of which are not quite correct, like the i387
 fpsetround.
 
 > and actually following patch also make dtoa work on NWS-3470 (MIPS1)
 > even with the default DBG=-O2:
 > ...
 > +.if ${MACHINE_CPU} == "mips"
 > +CPPFLAGS+=-DTrust_FLT_ROUNDS
 > +.endif
 
 Can you share the output of `objdump -dr dtoa.pico' in libc built with
 and without this flag to compare?
 
 Does the problem manifest if you statically link libc too?