Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

[Jeff Law <jeffreyalaw@gmail.com>]

On 5/31/23 10:25, Vineet Gupta wrote:
> Multilib testing on trunk is currently busted (and surprisingly this
> affects any/all targets but it seems nobody cares). We currently get the
> following splat:
> 
> | ERROR: tcl error code NONE
> | ERROR: torture-init: torture_without_loops is not empty as expected
> 
> And this takes down pretty much all of testsuite.
> 
> |               ========= Summary of gcc testsuite =========
> |                            | # of unexpected case / # of unique unexpected case
> |                            |          gcc |          g++ |     gfortran |
> | rv64imafdc/  lp64d/ medlow | 5421 /     4 |    1 /     1 |   72 /    12 |
> | rv32imafdc/ ilp32d/ medlow | 5422 /     5 |    3 /     2 |   72 /    12 |
> |   rv32imac/  ilp32/ medlow |  391 /     5 |    3 /     2 |  109 /    19 |
> |   rv64imac/   lp64/ medlow | 5422 /     5 |    1 /     1 |  109 /    19 |
> 
> There have been recent improvements in test harness around pairing of
> torture-{init,finish} and checking for leaking torture options. This
> however triggers a latent bug introduced way back in 2009: commit 3dd1415dc88
> "i386-prefetch.exp: Skip tests when multilib flags contain -march" which
> missed a pairing torture-finish. It was benign so far but in the new
> regime it causes extra state "torture-init-done" confusing the 2nd round of
> tests (in multilib).
> 
> This fix moves the early exit outside of torture-{init,finish} bracket
> and brings RISC-V testing back to sanity.
> 
> | rv64imafdc/  lp64d/ medlow |    3 /     2 |    1 /     1 |   72 /    12 |
> | rv32imafdc/ ilp32d/ medlow |    4 /     3 |    3 /     2 |   72 /    12 |
> |   rv32imac/  ilp32/ medlow |    3 /     2 |    3 /     2 |  109 /    19 |
> |   rv64imac/   lp64/ medlow |    5 /     4 |    1 /     1 |  109 /    19 |
> 
> gcc/testsuite:
> 	* gcc.misc-tests/i386-prefetch.exp: Move early return outside
> 	  the torture-{init,finish}
OK after addressing Thomas's comments which I think just amounted to 
moving the code to a different place and adjusting the comments in the 
commit message.

jeff