compiler verifications for NetBSD test suite

[Erik Fair <fair%netbsd.org@localhost>]

I presume that our code has variants of the sort of structure described below wherein the particular behavior of compilers is assumed, and that bad things happen when those assumptions are violated. As part of verifying the behavior of new versions of the compilers we use, we may need to modify our compiler test suite to verify the compiler behavior assumptions we make, e.g., store a copy in the test suite of expected compiler output for these critical sections of code, and diff them against what a new compiler emits to make sure that:

	* there are no changes in compiler-emitted assembler or object, or

	* review changes and see that they’re harmless, or change our code (as below) to match.

I bet this sort of bug has bitten us more than once.

	Erik


> On Dec 8, 2020, at 20:02, Valeriy E. Ushakov <uwe%netbsd.org@localhost> wrote:
> 
> Module Name:	src
> Committed By:	uwe
> Date:		Wed Dec  9 04:02:20 UTC 2020
> 
> Modified Files:
> 	src/sys/arch/sparc/sparc: pmap.c
> 
> Log Message:
> sp_tlb_flush() - fix inline asm miscompiled by newer gcc versions.
> 
> As one national park director once said: "my problems start when the
> dumber of my visitors meet the smarter of my bears".
> 
> Old inline asm used specific hardcoded registers "assuming that gcc
> doesn't do anything funny with these".  Unfortunately now it does,
> especially when this function is inlined.  We ended up restoring a
> wrong context.  The result was mysterious infinite memory faults.
> 
> Rewrite in safer inline asm, so that gcc is not confused.
> 
> Many thanks to chs@ for his patience.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.367 -r1.368 src/sys/arch/sparc/sparc/pmap.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>