On 18 May 2015 at 20:25, Mike Stump <mikest...@comcast.net> wrote: > 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. ?
Thanks for having a look at this problem. I thought about this a while ago, and was wondering whether the guard shouldn't be "are we using qemu?". Indeed as Mike, other simulators might support fork and threads quite well. > > 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. I believe qemu broken support for threads is a well-known issue. For instance: https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02156.html > 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.
