On May 18, 2015, at 8:01 AM, Alan Lawrence <alan.lawre...@arm.com> wrote: > Simulators such as qemu report the presence of fork (it's in glibc) but > generally do not support synchronization primitives between threads, so any > tests using fork are unreliable.
Hum, I have a simulator (binutils/sim) that has fork. All those tests pass for me. They seem to be reliable for me. I didn’t do anything special as I recall. ? I did add enough libc (aka newlib) to bootstrap gcc, which maybe is slightly more than some do, but, existence of additional libraries shouldn’t change it much. To the extent it does, it should be easy to notice any extra required libraries directly. If a qmu bug or design deficiency, do you have a pointer to the reported bug or the design where they talk about tit. Remember, the point of the test suite is to find bugs to be fixed. Papering over bugs by turning it off, is fine, but, we should have named bug reports that when fixed, cause us to go back and turn back on those that were turned off. > This patch disables the subset of such tests that identify themselves using > dg-require-fork. > > At present, such tests are limited to (a) gcc.dg/torture/ftrapv-1.c. and (b) > some tests in the 27_io section of the libstdc++ testsuite, listed below. > Further patches can add dg-require-fork to the many other tests that call > fork(). > > Cross-tested on aarch64-none-linux-gnu using qemu, with these tests becoming > UNSUPPORTED: > > (gcc) > gcc.dg/torture/ftrapv-1.c So, I reviewed this test case. What about it doesn’t work? Kinda simple and small, easy to understand. > Is this patch OK for trunk? No. Let’s talk about it before turning off a to of test cases.
