Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

[Hans-Peter Nilsson <hp@axis.com>]

> From: Mike Stump <mikestump@comcast.net>
> Date: Fri, 9 Jun 2023 10:18:45 -0700

> On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> > 
> > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
> > about 10 minutes to run for cris-elf in the "gdb simulator"
> 
> I'd let the libstdc++ people comment on specific things.
> I'll comment on general things.  We could let line count
> (or word count or character count) scale the timeout in
> part, we could record times in a db and put an expected
> run time into test cases or in an along side db. We could
> have factors for slow systems, slow simulators. A 5 GHz
> x86_64 will likely be faster that a 40 year old pdp11. We
> can have these scale factors trigger off OS, cpu
> statically, and/or we can do a quick bogomips calculation
> and let that scale it and record that scaling factor in
> the build tree.

Wild plans, but with some points.

Beware that uniform testing IMO weighs in much heavier than
uniform test-time.  Like, arm-eabi, rv32-elf and cris-elf,
having common main factors, should test the same code and
the same number of iterations, preferably regardless of
simulator quality.  (FWIW, I consider the cris-elf gdb
simulator is *fast* - before 2021 or when built
--disable-sim-hardware.)

> A wealth of possibilities.

And complexity!

> Solutions that require maintenance or test case
> modification are annoying.

Yeah, but that maintenance annoyance unfortunately includes
initial setup.  You propose quite a major shift there.  It
sounds good, but sorry, but I must settle for just editing
the test-case some way.

brgds, H-P