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

[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 wrong results onR3000mipseb
Date: Fri, 3 Nov 2023 22:44:47 +0900

 > Interesting. The _same_ binary behaves differently. Rules out a compiler bug
 > --well, almost.
 > 
 > Can you try a new binary with /usr/src/lib/libc/gdtoa/misc.c compiled in as
 > well:
 > 
 > cc -I/usr/src/lib/libc/gdtoa/ -I/usr/src/lib/libc/arch/mips/gdtoa/ \
 >    -DDEBUG -DHonor_FLT_ROUNDS -DNO_LONG_LONG -o m m.c \
 >    /usr/src/lib/libc/gdtoa/dtoa.c \
 >    /usr/src/lib/libc/gdtoa/dmisc.c \
 >    /usr/src/lib/libc/gdtoa/misc.c
 > 
 > This way, the resulting binary won't pickup _any_ gdtoa funcs. from libc.
 > (Previously, the stuff in misc.c came from the libc on the running machine
 >   which may have been optimized.)
 
 Ah, sorry, I specified a wrong source (not dtoa.c but gdtoa.c)..
 
 >> > news3470-% cc -I/s/netbsd-9/src/lib/libc/gdtoa/ -I/s/netbsd-9/src/lib/libc/arch/mips/gdtoa/ -DDEBUG -DHonor_FLT_ROUNDS -DNO_LONG_LONG -o m m.c /s/netbsd-9/src/lib/libc/gdtoa/gdtoa.c /s/netbsd-9/src/lib/libc/gdtoa/dmisc.c
 
 I've also tried again with misc settings:
 
 On NWS-3470:
 ---
 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-% cc -I/s/netbsd-9/src/lib/libc/gdtoa/ -I/s/netbsd-9/src/lib/libc/arch/mips/gdtoa/ -DDEBUG -DHonor_FLT_ROUNDS -DNO_LONG_LONG -o m0 m.c /s/netbsd-9/src/lib/libc/gdtoa/gdtoa.c /s/netbsd-9/src/lib/libc/gdtoa/dmisc.c
 news3470-% cc -I/s/netbsd-9/src/lib/libc/gdtoa/ -I/s/netbsd-9/src/lib/libc/arch/mips/gdtoa/ -DDEBUG -DHonor_FLT_ROUNDS -DNO_LONG_LONG -o m m.c /s/netbsd-9/src/lib/libc/gdtoa/dtoa.c /s/netbsd-9/src/lib/libc/gdtoa/dmisc.c 
 news3470-% cc -I/s/netbsd-9/src/lib/libc/gdtoa/ -I/s/netbsd-9/src/lib/libc/arch/mips/gdtoa/ -DDEBUG -DHonor_FLT_ROUNDS -DNO_LONG_LONG -o m2 m.c /s/netbsd-9/src/lib/libc/gdtoa/dtoa.c /s/netbsd-9/src/lib/libc/gdtoa/dmisc.c /s/netbsd-9/src/lib/libc/gdtoa/misc.c
 news3470-% cc -O2 -I/s/netbsd-9/src/lib/libc/gdtoa/ -I/s/netbsd-9/src/lib/libc/arch/mips/gdtoa/ -DDEBUG -DHonor_FLT_ROUNDS -DNO_LONG_LONG -o m2-O2 m.c /s/netbsd-9/src/lib/libc/gdtoa/dtoa.c /s/netbsd-9/src/lib/libc/gdtoa/dmisc.c /s/netbsd-9/src/lib/libc/gdtoa/misc.c
 news3470-% ./m0
 .O
 40490FD0
 3.0
 439D145A
 ?.0
 44C45970
 news3470-% ./m
 3.1
 40490FD0
 314.1
 439D145A
 1570.7
 44C45970
 news3470-% ./m2
 3.1
 40490FD0
 314.1
 439D145A
 1570.7
 44C45970
 news3470-% ./m2-O2 
 .O
 40490FD0
 3*5.8
 439D145A
 ?*8.7
 44C45970
 news3470-% 
 ---
 (the above '*'s are 8bit Japanese "katakana" chars)
 
 On NWS-5000:
 ---
 (copy all binaries from the above NWS-3470)
 news5000-% grep ^cpu /var/run/dmesg.boot
 cpu0 at mainbus0: MIPS R4400 CPU (0x450) Rev. 5.0 with MIPS R4010 FPC Rev. 0.0
 cpu0: 48 TLB entries, 16MB max page size
 cpu0: 16KB/16B direct-mapped L1 instruction cache
 cpu0: 16KB/16B direct-mapped write-back L1 data cache
 cpu0: 1024KB/64B direct-mapped write-back L2 unified cache
 news5000-% ./m0
 3.1
 40490FD0
 314.1
 439D145A
 1570.7
 44C45970
 news5000-% ./m
 3.1
 40490FD0
 314.1
 439D145A
 1570.7
 44C45970
 news5000-% ./m2
 3.1
 40490FD0
 314.1
 439D145A
 1570.7
 44C45970
 news5000-% ./m2-O2
 3.1
 40490FD0
 314.1
 439D145A
 1570.7
 44C45970
 news5000-% 
 
 ---
 
 So at least gcc -O2 (including dtoa.c in libc.so) causes
 something wrong on MIPS1.
 
 (I still wonder if it's compiler bug or improper implementation like
  undefined behaviour etc.)
 
 ---
 Izumi Tsutsui