id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
3377	interlocked pointer exchanges cause warnings with mingw64	anonymous	Peter Dimov	"With a gcc build targeting Win64 (specifically http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Release%20for%20GCC%204.4.0/mingw-w64_x86-64_linux64-4.4.0-1.tar.bz2/download), I'm seeing warnings like this:

/home/martind/work/unicorn/include/x86_64_mingw32w64/boost/thread/win32/interlocked_read.hpp: In function 'void boost::detail::interlocked_write_release(void* volatile*, void*)':
/home/martind/work/unicorn/include/x86_64_mingw32w64/boost/thread/win32/interlocked_read.hpp:71: error: cast from 'void*' to 'long int' loses precision
...
/home/martind/work/unicorn/include/x86_64_mingw32w64/boost/thread/win32/basic_timed_mutex.hpp: In member function 'void* boost::detail::basic_timed_mutex::get_event()':
/home/martind/work/unicorn/include/x86_64_mingw32w64/boost/thread/win32/basic_timed_mutex.hpp:152: error: cast from 'void*' to 'long int' loses precision
cc1plus: warnings being treated as errors

The warnings come from the casts here in boost/detail/interlocked.hpp:

# define BOOST_INTERLOCKED_COMPARE_EXCHANGE_POINTER(dest,exchange,compare) \
    ((void*)BOOST_INTERLOCKED_COMPARE_EXCHANGE((long volatile*)(dest),(long)(exchange),(long)(compare)))
# define BOOST_INTERLOCKED_EXCHANGE_POINTER(dest,exchange) \
    ((void*)BOOST_INTERLOCKED_EXCHANGE((long volatile*)(dest),(long)(exchange)))

On Win64, I see that sizeof(long) == 4 but sizeof(void*) == 8, so the compiler is right to warn.  Elsewhere in this file, InterlockedCompareExchangePointer and InterlockedExchangePointer are conditionally used to implement these macros.  Comments I found elsewhere suggested that this is done conditionally because these functions aren't available in very old platform SDKs and, indeed, MSDN says that they only became available with Windows 2000.  Perhaps Win64 can be assumed to have these functions available, as is assumed earlier in the file when compiling with MSVC.  gcc for Win64 is a relatively new development without wide deployment, which could explain why the branch that handles __CYGWIN__ etc doesn't yet cope.

In the attached patch, I've used the same condition for detecting Win64 as used in the MSVC part of the file.  That means that I've changed the behavior for IA64 as well as AMD64, despite having no means to test IA64.

I see interlocked.hpp is used by interprocess, smart_ptr and thread but I'm not sure which Component it ""belongs"" to, so I've left that set to None."	Bugs	closed	To Be Determined	None	Boost 1.39.0	Problem	fixed