Hi, the macro __IBMCPP__ at z/OS is "41130" for my system. The output of xlc++ -qversion is z/OS V1.13 XL C/C++. For AIX the macro __IBMCPP__ evaluates to "1210" and "xlc++ -qversion" evaluates to: IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0004. So we really have two different compilers for z/OS and AIX, with different versioning and behaviour. Best regards, Kilian. On 22 October 2013 16:13, Bjorn Reese wrote:

On 10/22/2013 04:01 PM, Peter Dimov wrote:

It's more likely that the z/OS compiler is a later version. What is the

...

value of __IBMCPP__ for the two compilers?

While I agree with this, please notice that although __IBMCPP__ is defined on both AIX and z/OS, their syntax are different. You can find a workaround in the "IBM z/OS C/C++" section:

http://sourceforge.net/p/**predef/wiki/Compilers/http://sourceforge.net/p/predef/wiki/Compilers/

______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boosthttp://lists.boost.org/mailman/listinfo.cgi/boost

the macro __IBMCPP__ at z/OS is "41130" for my system. The output of xlc++ -qversion is z/OS V1.13 XL C/C++.

For AIX the macro __IBMCPP__ evaluates to "1210" and "xlc++ -qversion" evaluates to:

IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0004.

So we really have two different compilers for z/OS and AIX, with different versioning and behaviour.

Thanks for all the info! There are a lot of workarounds predicated on __IMBCPP__ in type_traits, can you try search-and-replacing all of them to __xlC__ and then run the tests in libs/type_traits/test with your compiler? Many thanks, John.

...

Thanks for all the info! There are a lot of workarounds predicated on __IMBCPP__ in type_traits, can you try search-and-replacing all of them to __xlC__ and then run the tests in libs/type_traits/test with your compiler?

A bit of a problem here is that, according to the Predef wiki, __IBMCPP__ is VVRP decimal, whereas __xlC__ is VVRR hexadecimal (and I'm not sure what that means for, say, version 12.10, 0x0C0A or 0x1210), so the translation may not be entirely straightforward.

I know :-( However most of those predicated on version number are old workarounds, so we can probably just leave those and change the unconditional ones. John.

Hi, I did not try to replace the macros, yet. I will try this that evening, together with running the unit tests, as this is more time consuming. For the macro expansion, we have the following: 1. AIX compiler IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0004 "__xlC__" = 0x0c01 "__xlC_ver__" = 0x00000004 "__IBMC__" = __IBMC__ "__IBMCPP__" = 1210 "__COMPILER_VER__" = __COMPILER_VER__ "__MVS__" = __MVS__ 2. z/OS Compiler z/OS V1.13 XL C/C++ "__xlC__" = __xlC__ "__xlC_ver__" = __xlC_ver__ "__IBMC__" = __IBMC__ "__IBMCPP__" = 41130 "__COMPILER_VER__" = 0x410D0000 "__MVS__" = 1 I exchanged an email with a guy from IBM and they internally use the __MVS__ macro for differentiation between the two compilers and then differentiate between the versions in a following step. This is because MVS was the predecessor of z/OS, so it is easy for mainframe people to see, that __MVS__ does indeed mean mainframe. Best regards, Kilian. On 23 October 2013 10:51, Bjorn Reese wrote:

On 10/22/2013 10:52 PM, Peter Dimov wrote:

__IBMCPP__ is VVRP decimal, whereas __xlC__ is VVRR hexadecimal (and I'm

...

not sure what that means for, say, version 12.10, 0x0C0A or 0x1210), so

According to the compiler documentation [1], it ought to be 0x0C0A, but I would prefer to see the actual value from the compiler first.

[1] http://www-01.ibm.com/support/**docview.wss?uid=swg27024210&**aid=1http://www-01.ibm.com/support/docview.wss?uid=swg27024210&aid=1

______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boosthttp://lists.boost.org/mailman/listinfo.cgi/boost

Hi Peter, my version of IBM XL C++ 12.1 still has this bug. Only the z/OS version doesn't have this bug, as I wrote. Unfortunately I have not been able to build a recent version of Boost on z/OS to test, which other bugs the z/OS compiler does not have. There are simply too many other errors, even in type_traits. In the project I am involved, we use a (very large) subset of type_traits from Boost 1.49, which is also the last version working on Solaris. In this subset, everything works except of remove_bounds, as I wrote. For 1.54, not much works on z/OS. But it is difficult to test, because Boost::Build is, of course, also broken :-). For 1.49 I converted everything to GNU make manually. So, as porting Boost to z/OS seems to be difficult, just ignore me. I am perhaps stuck to port file by file to z/OS as I need it. But changing the IBMCPP macro to the xlC macro seems to be wise, anyhow. Best regards, Kilian. On 24 October 2013 16:11, Peter Dimov wrote:

I have a similar problem in shared_ptr, as reported in ticket #8823:

https://svn.boost.org/trac/**boost/ticket/8823https://svn.boost.org/trac/boost/ticket/8823

However, the IBM Canada tester, XL C/C++ 12.1.0.4 on AIX, is all green.

I'd like to fix #8823, but what version should I use in the workaround? It seems that XL C++ 12.1 on AIX no longer has this [] vs [N] bug; is that correct?

______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boosthttp://lists.boost.org/mailman/listinfo.cgi/boost