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

[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: gnats-bugs%netbsd.org@localhost
Cc: rvp%SDF.ORG@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: port-mips/57680: printf("%.1f") shows wrong results on R3000mipseb
Date: Tue, 7 Nov 2023 22:54:06 +0900

 >  Looking at the dump, I see that in the inline case, we have:
 >  
 >           .type   __dtoa, @function
 >    __dtoa:
 >   	[...]
 >   	.set    reorder
 >   	[...]
 >   	cfc1 $2,$31
 >   	andi    $2,$2,0x3
 >   	[...]
 >  
 >  while in the non-inline case, it is:
 >  
 >           .type   __dtoa, @function
 >    __dtoa:
 >   	[...]
 >           .set    noreorder
 >   	[...]
 >           .reloc  1f,R_MIPS_JALR,__libc_fegetround_ref
 >    1:     jalr    $25
 >   	[...]
 >  
 >  which would mean that here the fegetround() (which does its own
 >  `.set noreorder') -> __rfs() instructions are all strictly ordered.
 >  Whereas in the present (inlined) case, all those instructions may be
 >  ordered differently.
 
 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)
 
 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/908b1c665b560052b06b4d21f69fbbceb4092dc7 
  https://github.com/NetBSD/src/commit/b23f3dbe357baf334f01e266af68692bf25626ac
  https://github.com/NetBSD/src/commit/a75c7827423046c581d7fa1183c8d13788769ddd
  https://github.com/NetBSD/src/commit/7e1a38b9b3ea99b4845d8a315c742d8b27640d29
 
 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..
 
 ---
 Izumi Tsutsui