On Fri, 16 Sep 2016, László Böszörményi wrote:
On Fri, Sep 16, 2016 at 11:56 AM, Niko Tyni <nt...@debian.org> wrote:
On Tue, Sep 13, 2016 at 10:48:42PM -0500, Bob Friesenhahn wrote:
It may be necessary to prove where the problem is occuring by manually
overwriting updated files in the magick directory with those from the
previous working version until the problem goes away (assuming that it
does).
I've bisected it to
https://sourceforge.net/p/graphicsmagick/code/ci/4ee2a87a67e064f3a094ee30b40a7a9bba1eb727/
Use clock_gettime() to obtain elapsed time.
Indeed, confirmed that reverting this commit fixed the compilation on ppc64el.
Thanks for your work, I was too slow doing it. :(
- it also goes away if LockSemaphoreInfo() in magick/semaphore.c is
optimized with -O0, which seems weird
Do you mean that this alone is enough to fix this issue?
I haven't found the exact optimization that's triggering it yet,
and I haven't looked at the code GCC generates.
It seems to be a GCC code defect, as you noted that even GCC 5 fails
to generate a working code.
I think I'll use the -O0 compilation workaround, don't want to further
delay the Perl transition.
This is all very strange. I am not seeing a problem with the source
code. I thought that the crash was happening at line 301 of log.c (at
LockSemaphoreInfo()), and the first use of the timer APIs is at line
318 of log.c so this new code should not even be invoked yet.
As far as I am aware, whole library/program optimization is not in use
so there should not be intimate coupling between the timer and
semaphore code.
Are you able to easily change the optimization of semaphore.c or log.c
(maybe by injecting an optimization pragma into the code)?
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
