Hi Robert et al,
I tried to compile OSG with QT Creator using MinGW and GCC 4.8.2.
It worked pretty well. But I found a case of ambiguous defines in Atomic.cpp in
OpenThreads.
The problem is that both:
_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS
and
_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED
is defined. This gives the following problems.
1. Since _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED is defined we will enter the
section:
Code:
#if defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
#include <windows.h>
#include <intrin.h>
#pragma intrinsic(_InterlockedAnd)
#pragma intrinsic(_InterlockedOr)
#pragma intrinsic(_InterlockedXor)
#endif
Which will result in warnings since intrinsic in an unknown pragma for GCC. But
since _InterlockedAnd, _InterlockedOr and _InterlockedXor ARE defined inside
intrin.h on MinGW it will work. So the pragma lines should only be run if we
are using MSVC.
2. But in the atomic operators we will not be able to use the previously
defined intrinsics, due to the fact that _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS
is defined. The compiler will never reach the code inside
_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED.
Example:
Code:
unsigned
Atomic::operator++()
{
#if defined(_OPENTHREADS_ATOMIC_USE_GCC_BUILTINS)
return __sync_add_and_fetch(&_value, 1);
#elif defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED)
return InterlockedIncrement(&_value);
#elif defined(_OPENTHREADS_ATOMIC_USE_BSD_ATOMIC)
return OSAtomicIncrement32(&_value);
#else
# error This implementation should happen inline in the include file
#endif
}
I do not know if there are any benefits of using one or the other. But I do not
think we should define both.
Best regards,
Björn
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=60356#60356
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
