> From: Patrick Palka <ppa...@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
