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

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

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/908b1c665b560052b06b4d21f69fbbceb4092dc7 
>   https://github.com/NetBSD/src/commit/b23f3dbe357baf334f01e266af68692bf25626ac
>   https://github.com/NetBSD/src/commit/a75c7827423046c581d7fa1183c8d13788769ddd
>   https://github.com/NetBSD/src/commit/7e1a38b9b3ea99b4845d8a315c742d8b27640d29

Can you please try this experiment to hopefully rule in/out simple CP1 hazards?

In sys/arch/mips/include/fenv.h change __rfs() to add two nops before using
the result:

	__asm __volatile(
	    ".set push\n"
	    ".set noreorder\n"
	    "cfc1 %0,$31\n"
	    "nop\n"
	    "nop\n"
	    ".set pop" : "=r" (__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" : "=r" (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.