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

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

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

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: rvp%SDF.ORG@localhost
Cc: gnats-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-mips/57680: printf("%.1f") shows wrongresultsonR3000mipseb
Date: Sun, 5 Nov 2023 14:28:31 +0900

 > > 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?
 
 It's a bit annoying to prepare full 10.0_BETA environment
 on the slow machine, so I test your previous test program on 9.3:
 ---
 news3470-% ./m2
 3.1
 40490FD0
 314.1
 439D145A
 1570.7
 44C45970
 news3470-% ./m2 | hexdump -Cv
 00000000  33 2e 31 0a 34 30 34 39  30 46 44 30 0a 33 31 34  |3.1.40490FD0.314|
 00000010  2e 31 0a 34 33 39 44 31  34 35 41 0a 31 35 37 30  |.1.439D145A.1570|
 00000020  2e 37 0a 34 34 43 34 35  39 37 30 0a              |.7.44C45970.|
 0000002c
 news3470-% ./m2-O2
 .O
 40490FD0
 3*-5.8
 439D145A
 ?*8.7
 44C45970
 news3470-% ./m2-O2 | hexdump -Cv
 00000000  2e 4f 0a 34 30 34 39 30  46 44 30 0a 33 c4 35 2e  |.O.40490FD0.3.5.|
 00000010  38 0a 34 33 39 44 31 34  35 41 0a 3f d9 38 2e 37  |8.439D145A.?.8.7|
 00000020  0a 34 34 43 34 35 39 37  30 0a                    |.44C45970.|
 0000002a
 news3470-% 
 ---
 
 The problem (or compiler issue?) seems more complicated.
 
 > 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
 > ```
 
 Not quite, but it looks optimization changes behaviours.
 
 To test with various libc binaries, I've prepared separate directories
 and put libc binaries there, and use LD_LIBRARY_PATH on tests:
 
 1) ./libc-9.3 : libc.so.12.213 binary from NetBSD 9.3 release base.tgz
 2) ./libc-O2  : libc.so.12.213 built from 9.3 src/lib/libc here
 3) ./libc-O2-and-quorem-O0 :
                 libc.so.12.213 built from 9.3 src/lib/libc
                 with the above "force optimize(0) against quorem()" patch
 4) ./libc-O1  : libc.so.12.213 built with DBG=-O1 from 9.3 src/lib/libc
 5) ./libc-O0  : libc.so.12.213 built with DBG=-O0 from 9.3 src/lib/libc
 
 ---
 news3470-% uname -a
 NetBSD galant 9.3 NetBSD 9.3 (GENERIC) #0: Sat Nov  4 23:42:11 JST 2023  tsutsui@mirage:/s/tsutsui/netbsd-src/sys/arch/newsmips/compile/obj.newsmips/GENERIC newsmips
 news3470-% grep ^cpu /var/run/dmesg.boot
 cpu0 at mainbus0: MIPS R3000 CPU (0x220) Rev. 2.0 with MIPS R3010 FPC Rev. 2.0
 cpu0: 64KB/4B direct-mapped Instruction cache, 64 TLB entries
 cpu0: 64KB/4B direct-mapped write-through Data cache
 news3470-% cat test.c
 #include <stdio.h>
 
 int
 main(int argc, char *argv[])
 {
         float f;
 
         f = 3.14159 * 100;
         printf("%.1f\n", f);
         printf("%d\n", (int)f);
 
         f = f * 5;
         printf("%.1f\n", f);
         printf("%d\n", (int)f);
 }
 news3470-% cc -o test test.c
 news3470-% env LD_LIBRARY_PATH=libc-9.3 ldd ./test
 ./test:
         -lc.12 => libc-9.3/libc.so.12
 news3470-% env LD_LIBRARY_PATH=libc-9.3 ./test
 300.0
 314
 ?00.0
 1570
 news3470-% env LD_LIBRARY_PATH=libc-O2 ldd ./test
 ./test:
         -lc.12 => libc-O2/libc.so.12
 news3470-% env LD_LIBRARY_PATH=libc-O2 ./test
 300.0
 314
 ?00.0
 1570
 news3470-% env LD_LIBRARY_PATH=libc-O2-and-quorem-O0 ldd ./test
 ./test:
         -lc.12 => libc-O2-and-quorem-O0/libc.so.12
 news3470-% env LD_LIBRARY_PATH=libc-O2-and-quorem-O0 ./test
 300.0
 314
 ?00.0
 1570
 news3470-% env LD_LIBRARY_PATH=libc-O1 ldd ./test
 ./test:
         -lc.12 => libc-O1/libc.so.12
 news3470-% env LD_LIBRARY_PATH=libc-O1 ./test
 314.1
 314
 ?70.7
 1570
 news3470-% env LD_LIBRARY_PATH=libc-O0 ldd ./test
 ./test:
         -lc.12 => libc-O0/libc.so.12
 news3470-% env LD_LIBRARY_PATH=libc-O0 ./test
 314.2
 314
 1570.8
 1570
 news3470-% 
 ---
 
 I'll try to check which function actually requires -O0 later.
 (a bit boring work on the slow machine..)
 
 ---
 Izumi Tsutsui