[shared_ptr] Using inline assembler, Microsoft syntax in Linux, and shared pointers
All, To make a long story short, here's my situation: - we just upgraded to boost 1.33 from 1.32; - trying to compile on Linux (Windows will follow soon); we're mostly using gcc, with the exception of some pieces that we use Intel C++ 9.x for; - some piece of the code I'm trying to build uses boost shared pointers and, being a port from Windows, inline Microsoft-style assembler code; - the rest of my 'world' is built in an environment that causes boost/detail/sp_counted_base_gcc_x86.hpp to be used for the shared_ptr locking. The problem I ran into is that, well, boost/detail/sp_counted_base_gcc_x86.hpp contains gnu-style inline assembler, and icc (intel C++ compiler) refuses to mix the 2 assembler styles in one file. After a little snooping around, I found that there is a file called boost/detail/sp_counted_base_cw_x86.hpp, which contains the equivalent functionality as *gcc_x86.hpp, only written in Microsoft-style assembly. I rigged it to use this and it 'seems' to work. And now for the questions: - is there any reason why in my release the #include of the *cw_x86.hpp file was commented out? Is it not performing as it should? Any other reasons? - is it safe for me to compile part of my classes with *gcc_x86.hpp, and part with *cw_x86.hpp? - if the above answers are 'favorable', is it possible for future releases to include a way for people to easily have the MS-assembly file included instead of the gnu one? Thanks a lot, Ovidiu
Ovidiu Cristea wrote:
All,
To make a long story short, here's my situation: - we just upgraded to boost 1.33 from 1.32; - trying to compile on Linux (Windows will follow soon); we're mostly using gcc, with the exception of some pieces that we use Intel C++ 9.x for; - some piece of the code I'm trying to build uses boost shared pointers and, being a port from Windows, inline Microsoft-style assembler code; - the rest of my 'world' is built in an environment that causes boost/detail/sp_counted_base_gcc_x86.hpp to be used for the shared_ptr locking.
The problem I ran into is that, well, boost/detail/sp_counted_base_gcc_x86.hpp contains gnu-style inline assembler, and icc (intel C++ compiler) refuses to mix the 2 assembler styles in one file.
A very unusual situation. :-)
After a little snooping around, I found that there is a file called boost/detail/sp_counted_base_cw_x86.hpp, which contains the equivalent functionality as *gcc_x86.hpp, only written in Microsoft-style assembly. I rigged it to use this and it 'seems' to work.
And now for the questions: - is there any reason why in my release the #include of the *cw_x86.hpp file was commented out? Is it not performing as it should? Any other reasons?
It wasn't tested as extensively as the others and there was no need for it since CodeWarrior/Windows works with sp_counted_base_w32.
- is it safe for me to compile part of my classes with *gcc_x86.hpp, and part with *cw_x86.hpp?
In principle, this is a violation of the One Definition Rule... In practice, it should work.
- if the above answers are 'favorable', is it possible for future releases to include a way for people to easily have the MS-assembly file included instead of the gnu one?
It would probably be better to introduce an Intel-specific sp_counted_base that uses its intrinsics. I don't know whether the Intel compiler for Linux supports the _Interlocked* family, though; or whether the following intrinsics: http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html that were originally introduced in icc/ia64 (and later adopted by g++ 4.1) work under icc/x86.
Thanks for replying so fast! I know this is a unusual case, but one that occurred nonetheless. As I said, I had already created a simple test that seems to be OK, just wanted to know if there might be any other obvious (for you) pitfalls. I'll let you know if I find anything else, good or bad. Since this seems to work, I can only hope there are no plans to discontinue this piece of code in future versions. Thanks again for the clarifications. Best regards, Ovidiu Peter Dimov wrote:
A very unusual situation. :-)
It wasn't tested as extensively as the others and there was no need for it since CodeWarrior/Windows works with sp_counted_base_w32.
In principle, this is a violation of the One Definition Rule... In practice, it should work.
It would probably be better to introduce an Intel-specific sp_counted_base that uses its intrinsics. I don't know whether the Intel compiler for Linux supports the _Interlocked* family, though; or whether the following intrinsics:
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
that were originally introduced in icc/ia64 (and later adopted by g++ 4.1) work under icc/x86.
participants (2)
-
Ovidiu Cristea -
Peter Dimov