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

[Simon Burge <simonb%NetBSD.org@localhost>]

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

From: Simon Burge <simonb%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: port-mips-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
    netbsd-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-mips/57680: printf("%.1f") shows wrong results on R3000mipseb
Date: Wed, 08 Nov 2023 02:24:49 +1100

 Hi Tsutsui,
 
 Izumi Tsutsui wrote:
 
 >  Per my understanding:
 >  - .reorder tells as(1) to reorder instructions for branch delay slot,
 >    and put necessary nop instructions to avoid instruction delay hazards
 >  - .noreorder tells as(1) assemble instructions as is (i.e. programmers
 >    have the responsivility of branch delay slots and delay hazards)
 
 This is correct.
 
 >  R3000 (MIPS1) CPUs requires proper nops to avoid delay hazards.
 >  R4x00 (MIPS3 and later) CPUS handle such hazards by hardware.
 >  =
 
 >  There were many hazard bugs that only affects MIPS1:
 >   https://github.com/NetBSD/src/commit/908b1c665b560052b06b4d21f69fbbceb=
 4092dc7 =
 
 >   https://github.com/NetBSD/src/commit/b23f3dbe357baf334f01e266af68692bf=
 25626ac
 >   https://github.com/NetBSD/src/commit/a75c7827423046c581d7fa1183c8d1378=
 8769ddd
 >   https://github.com/NetBSD/src/commit/7e1a38b9b3ea99b4845d8a315c742d8b2=
 7640d29
 
 Can you please try this experiment to hopefully rule in/out simple CP1 haz=
 ards?
 
 In sys/arch/mips/include/fenv.h change __rfs() to add two nops before usin=
 g
 the result:
 
 	__asm __volatile(
 	    ".set push\n"
 	    ".set noreorder\n"
 	    "cfc1 %0,$31\n"
 	    "nop\n"
 	    "nop\n"
 	    ".set pop" : "=3Dr" (__fpsr));
 
 In lib/libc/arch/mips/gen/flt_rounds.c change __flt_rounds() in a similar =
 way:
 
 	__asm __volatile(
 	    ".set push\n"
 	    ".set noreorder\n"
 	    "cfc1 %0,$31\n"
 	    "nop\n"
 	    "nop\n"
 	    ".set pop" : "=3Dr" (x));
 
 
 I have no idea why a number of the __asm()s for "cfc1" have ".set noat";
 nothing should be using the AT register here, so that doesn't make sense
 to me.  Let's ignore that for now though.
 
 Unfortunately I can't find a R3000 box here that powers on anymore so I
 can't test this locally.  :(
 
 If this helps, we might need to add CP1 hazards in lots more places.
 But then I don't understand why this used to work ... unless
 
 >  and this dtoa() behavior looks similar issue, but I don't have a clue
 >  if gcc (or our some asm sources) has a bug that triggers unexpected
 >  hazards in .set noreorder cases..
 
 This would seem like either a big regression or a distinct change of
 optimiser behaviour in newer gcc?  I haven't checked if glibc has any
 fancy handling for CP1 hazards.
 
 Cheers,
 Simon.