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

[RVP <rvp%SDF.ORG@localhost>]

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

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-mips/57680: printf("%.1f") shows wrong
 resultsonR3000mipseb
Date: Sat, 4 Nov 2023 23:48:41 +0000 (UTC)

 On Sat, 4 Nov 2023, Izumi Tsutsui wrote:
 >
 > I've tried printf "%.1f" on netbsd-10/202311031550Z with on NFS root.
 > A bit better, but still wrong result.
 >
 > (typed from framebuffer console)
 > ---
 > # uname -a
 > NetBSD	10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Fri Nov  3 10:27:30 UTC 2023  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/newsmips/compile/GENERIC newsmips
 > # ./a.out
 > 314.2
 > 314
 > ?70.8
 > 1570
 > #
 > ---
 >
 
 That `?' char. which is printed doesn't look random. In ASCII, '0' + 15 is
 '?'. So, it appears that instead of printing '1' and '5' individually, we
 see '0' + 15 = '?'. Is the katakana in some of the previous emails '0' + 70?
 
 Can you see if disabling optimizations for quorem() helps? dtoa() does
 '0' + quorem() in a few places. If it doesn't, try disabling optimizations
 for the whole of src/lib/libc/gdtoa/misc.c: If you recall, we saw these same
 wrong results when the optimized version in libc was used.
 
 ```
 diff -urN a/src/lib/libc/gdtoa/dmisc.c b/src/lib/libc/gdtoa/dmisc.c
 --- a/src/lib/libc/gdtoa/dmisc.c	2008-03-21 23:13:48.000000000 +0000
 +++ b/src/lib/libc/gdtoa/dmisc.c	2023-11-04 23:29:29.107072000 +0000
 @@ -104,6 +104,7 @@
   #endif
   	}
 
 +__attribute__ ((optimize(0)))
    int
   quorem
   #ifdef KR_headers
 ```
 
 -RVP