7 aug 2015 kl. 14.50 skrev Rainer Emrich rai...@emrich-ebersheim.de:
This fixes the issue, libgom.sum attached. Can we have this in head and in
4.x ?
That is probably the expedient solution even if we eventually get libgomp
fixed. (The patch adds an extra cycle or two on some critical paths
6 aug 2015 kl. 12.46 skrev Rainer Emrich sf.rai...@emrich-ebersheim.de:
Using the x86_64 runtime and winpthread from 4th of August I get a lot of
libgomp testsuite failures. Nearly all execution tests fail!!! That's a
regression against older runtime/winpthread versions.
I assume that's
For debugging issue can be used OpmeMP test
https://github.com/niXman/mingw-builds/blob/master/tests/omp_test.c
Build it with «gcc omp_test.c -fopenmp -o omp_test.exe» and run.
No crash when I run that code. Is this the same for everybody else?
Perhaps you could find a different test case.
19 jun 2015 kl. 23.12 skrev Alexandre Pereira Nunes alexandre.nu...@gmail.com:
I came across this: https://sourceforge.net/p/mingw-w64/bugs/344/
Does anyone knows if that's still the case?
Yes. There is a patch, but it has not been cleared for release yet. It may take
a few weeks more,
patch is ok. I am still a bit curious to learn about that high delay
caused by getenv ().
It was a while since I dissected it, but I believe getenv takes a lock. This
hurts multithreaded programs in particular. Even without a lock, getenv still
needs to do a linear string search through the
1 apr 2015 kl. 05.35 skrev Dongsheng Song dongsheng.s...@gmail.com:
In my testing, getenv() is very fast.
*) unset PRINTF_EXPONENT_DIGITS
preheat 1 times, then perform 100 times (use 4.6 seconds)
getenv cost: 4.6 us
*) set PRINTF_EXPONENT_DIGITS=3
preheat 1 times,
The functions in the __mingw_printf family are very slow because of the
getenv(”PRINTF_EXPONENT_DIGITS”) call that is made every time, even when that
information isn’t actually needed.
Please consider this patch. It only calls getenv once, caching the result (as
is traditionally done in
