In LLVM 15.0.5 2 tests nearly destroy all and I killed them.
libcxx/test/std/algorithms/alg.modifying.operations/alg.transform/ranges.transform.pass.cpp
libcxx/test/std/utilities/format/format.functions/format_to_n.locale.pass.cpp
In LLVM 15.0.5 2 tests nearly destroy all and I killed them.
libcxx/test/std/algorithms/alg.modifying.operations/alg.transform/ranges.transform.pass.cpp
libcxx/test/std/utilities/format/format.functions/format_to_n.locale.pass.cpp
In 16 I have the same problems as mentioned above in 15 with one test:
/libcxx/test/std/algorithms/alg.modifying.operations/alg.transform/ranges.transform.binary.pass.cpp
I am reporting it here since it may be dangerous in the future and also if someone wishes to check it. The rest 8000 tests run without problems.
It’s unclear what you mean by your extremely non-scientific “destroy HDD and RAM” claim, but clearly these tests are not destroying your hardware. I’m going to guess that what you mean is that some of them are quite computationally expensive, though whether you mean to compile or to run I don’t know. I will note though that the test you mention has since been split into two in order to halve its compile time, and perhaps reduce compiler memory usage too.
I notice it is repaired as well as the other one above which now runs without problems. However, it is impossible to investigate what happens since the computer crashes and the hdd burns. RAM is not low, swap also. There are no problems with the rest. Only this algorithm makes it. How about linking the test to the hardware and skipping it of it is not run on a supercomputer e.g, Even if run on a more powerful computer it may cause damages and how this algorithm is useful if it is dangerous,
I don’t know what you’re doing but you don’t need a supercomputer to run the libc++ test suite. We’ve run them under QEMU with full system emulation just fine. And no, it is not dangerous, I can promise you that.