2012/5/22 Antony Riakiotakis <[email protected]>
> Hi, thanks for the quick response. I will try to get a backtrace
> though last time I tried I remember I got some assembly mumbo-jumbo,
> related to openmp for certain(If memory serves right, something like
> omp_get_thread_name hit a null pointer or something similar).
> Unfortunately I don't have a unix 4.7 to verify the bug there, but
> regular MinGW 4.6.2 works fine. I would prefer to stick with 4.7 or
> 4.6.3 if possible.
> I was refering to optimization in terms of use of the compiler by a
> broad team of builders, not in terms of producing the buggy behaviour.
>
What do you mean by this exactly? I don't quite follow.
>
> quoting:
>
> """
> 1) release: released GCC versions, with the then latest MinGW-w64 CRT
> together with trunk binutils/gdb will be placed here. The two latter
> things are pretty much rock-solid, and binutils releases very little,
> so this makes sense. GCC will use plain "win32" threading, but the
> pthreads-based stuff in GCC (think libgomp) is still based on
> winpthreads. This should resolve all issues people are having with the
> posix-threading builds I've been pushing previously. This does mean no
> <thread> for C++.
> """
>
> This may well be the source of our problems
>
The ones in the "release" dir are not special, they just use mingw-w64's
winpthreads as a "backend" for libgomp. The Ray Linn builds use
pthreads-win32 (I think, looking at the pthreads headers, just like plain
MinGW. As we're seeing the problem on both sides, I don't think this is
related specifically to winpthreads itself. Rather a bug in libgomp seems
more likely at this point.
>
> """
> ....As before, these are now built with -mtune=corei7 and a bunch of
> other fancy optimization options I hope work as advertised.
> """
>
> This may be troublesome for people who don't own an i7
>
-mtune does nothing but perhaps minimally degrade performance of the
compiler executables on systems not an i7. It will still run like it should
on any other CPU. The other fancy options I'm talking about are
-fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity
-floop-interchange -floop-block -floop-parallelize-all
The first two are usual, the last four are Graphite loop transformations.
These have been in GCC since 4.5, so they should be pretty stable.
My new builds (along with the 4.5.3) will be built with
-march=nocona -mtune=core2
which means MMX/SSE/SSE2/SSE3, which in turn means anything on this list:
http://en.wikipedia.org/wiki/SSE3 which in turn is pretty much anything not
from the stone age.
I'll try to get something useful from my Blender build once I find the
time. What can I do to provoke the crash? The only crash I've experienced
is a crash-on-exit, which seemed quite harmless in the end.
Note we have had a report of OpenMP crashes before, but never got a code
sample where the failure occurs. So bear with me :)
Ruben
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
