[PATCH] libstdc++: testsuite: reduce max_size_type.cc exec time [PR113175]

[Hans-Peter Nilsson]

> From: Patrick Palka <ppalka@redhat.com>
> Date: Tue,  2 Jan 2024 12:48:26 -0500

> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and release
> branches (r14-205 was backported everywhere)?
> 
> -- >8 --
> 
> The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
> inadvertently increased the execution time of the test by over 5x due to
> enabling the two main loops to actually run in the signed_p case instead
> of being dead code.  This suggests that the current range of the loop is
> far too big and the test too time consuming, especially when run on
> simulators.
> 
> So this patch cuts the loop range by 10x as proposed in the PR.  This
> shouldn't significantly weaken the test since the same important edge
> cases are still checked in the new range.  On my x86_64 machine this
> reduces the test execution time by 10x, and 1.6x less time than before
> r14-205.
> 
> 	PR testsuite/113175
> 
> libstdc++-v3/ChangeLog:
> 
> 	* testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce
> 	'limit' to 100 from 1000 and adjust 'log2_limit' accordingly.
> 	(test03): Likewise.


Oh the irony...  This now fails for cris-elf.  For CRIS,
it's not a timeout but an actual failure.

See PR113226; suddenly 1*-100 == 4294967196.  You changed
the type of "limit" to unsigned, but that doesn't appear to
matter.  So why would *narrowing* the tested range yield an
error?

I can't tell if this is target-specific: not enough
32-bitters results for r14-6888-ga138b99646a555 and later on
gcc-testresults@ for libstdc++ yet.  (No, I don't count the
32-bit multilibs of x86_64 and s390x.)

brgds, H-P