On Fri, 17 Aug 2018 at 17:41, Thomas Koenig <tkoe...@netcologne.de> wrote: > > Hi Christophe, > Hi,
> sorry that this took so long, but a holiday followed by a > business trip seven timezones away can do that :-) > Sorry, I am on holidays too, and not back yet :) > > I applied this patch, and again I still see regressions on > > armeb-none-linux-gnueabihf > > --with-cpu cortex-a9 > > --with-fpu neon-fp16 > > The info that you supplied in the PR indicates some sort of library > problem exposed by the patch, possibly by including gthr.h. > > All Nicolas and I could come up with was to remove the async I/O > functionality from armeb-* and by xfailing the tests. > > This is done by > > +#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) && > !defined(__ARMEB__) > +#define ASYNC_IO 1 > +#else > +#define ASYNC_IO 0 > +#endif > > If somebody comes up with something more fine-grained for the > feature test, we can put this in now or later. > > Regression-tested on x86_64-pc-linux-gnu (which showed that > xfail lines in the testsuite aren't wildly inaccurate). > > So, I'd appreciate testing. If this passes, this will be > committed ASAP. > I tried this version of the patch, and I'm still seeing the regression on array_constructor_8.f90. I didn't try to run the new tests (I only applied the patch part) I'll try to investigate the PR a bit more when I'm back at the office (e/o August) Christophe > Regards > > Thomas >
