> From: Mike Stump <mikest...@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
