Apologies if this message might somehow be unsuitable in context and manner, but hopefully as PGI C++ users we can create some buzz on this issue.
I am using boost for everything these days. (www.boost.org). More than the standard C++ library itself. Are there any other users of this fine lib out there? (I am sure MANY! Please speak out.)
Boost libraries push C++ compilers to the limit, yet one way or another many compilers are supported (probably most were thanks to combined efforts of boost AND compiler vendors).
I can attest that PGI compiler is successfully living up to that limit: One can build and test many if not all boost libraries with current PGI compilers as is by modifying one of the simplest available bjam toolsets according to one’s PGI development environment. It works, but…
PGI is not officially supported by boost (or vice versa!). What does this mean? It means the user has to suffer trying to come up with a non-portable, (very!) underoptimized, quite nontrivial and extremely brittle build with every new version of the library.
We are currently working through the process of adding PGI support for Boost. We don’t have a firm time line yet, but it is a high priority item which we are actively pursuing.
what is the status of your support for boost. we are working on a product that is trying to use a small set of the boost library and are unable to proceed. while we are able to build the library with g++ we get the following error message using pgCC
/opt/PGI/pgi_6.2-4/linux86-64/6.2/bin/pgcpp1 --llalign -Dunix -D__unix -D__unix__ -Dlinux -D__linux -D__linux__ -D__NO_MATH_INLINES -D__x86_64__ -D__LONG_MAX__=9223372036854775807L ‘-D__SIZE_TYPE__=unsigned long int’ ‘-D__PTRDIFF_TYPE__=long int’ -D__THROW= -D__extension__= -D__amd64__ -D__SSE__ -D__MMX__ -D__SSE2__ -D__SSE3__ -D__PGI -I. -I/usr/include -I/usr/projects/blanca/packages/Loki/include -I/usr/projects/blanca/packages/UnitTest++/src -IContinuous/ENDF_Laws -IContinuous -IInterface_test -DGCC_FORT_COMPILER -DNDEBUG -DBOOST_DISABLE_ASSERTS -I/opt/PGI/pgi_6.2-4/linux86-64/6.2/include/CC -I/opt/PGI/pgi_6.2-4/linux86-64/6.2/include -I/usr/local/include -I/usr/lib/gcc/x86_64-redhat-linux/3.4.4/include -I/usr/lib/gcc/x86_64-redhat-linux/3.4.4//include -I/usr/include --dependencies_to_file_quoted_only /users/sdnolen/obj/pgi-opt-flash/Continuous/XsdirReader.d -q -o /tmp/sdnolen/pgcppZ9ObzfqWYEjN.il Continuous/XsdirReader.cc
“/usr/include/boost/cstdint.hpp”, line 71: error: the global scope has no
“int64_t”
using ::int64_t;
^
1 error detected in the compilation of “Continuous/XsdirReader.cc”.
pgCC-Fatal-cpp1 completed with exit code 2
We are still working on it. We recommend you try the latest release of our compilers to compile. Unfortunately we cannot tell the specific time when we will be able to compile it all.
The boost dev branch gets compile at Sandia at least weekly. You can find results and best flags to use on at:
With 7.0-7, I was able to compile some parts of Boost, provided I explicitely tell the compiler to undefine SSE2 (it seems 7.0-7 does not handle how Boost writes SSE code). Also, the thread library can’t be compiled.
It seems that there isn’t a PGI compiler in the Boost compilation farm. Any luck of having different versions back?
I know Sandia was working on getting our 8.0 compiler into their daily build of BOOST, so I’m not sure why we’re not on the list now. I’ll ask my contact there and see what’s going on.
FYI, we have made a lot progress with BOOST but still have more work to do.
However, when I try to link against the regex library, I get this error:
.gnu.linkonce.t.finalize__Q3_5boost9re_detail98basic_regex_creator__tm__71_cQ2_5boost58regex_traits__tm__38_cQ2_5boost25cpp_regex_traits__tm__2_cFPCZ1ZT1_v' referenced in section .data’ of ./libclustering_algorithm_pack.a(ccpivot.o): defined in discarded section `.gnu.linkonce.t.finalize__Q3_5boost9re_detail98basic_regex_creator__tm__71_cQ2_5boost58regex_traits__tm__38_cQ2_5boost25cpp_regex_traits__tm__2_cFPCZ1ZT1_v’ of ./libclustering_algorithm_pack.a(ccpivot.o)
It then continues for many pages in the same way, blah' referenced in section blah’ of blah: defined in discarded section blah'. Inspecting the ld’ online documentation it seems that pgcpp has created an empty section with a label in it. References to that label are causing the problem… On the one hand I can’t really see why this should be illegal… But on the other hand I can’t see why the C++ compiler would need to do this. Before I go inspecting the asm output, does anyone have any further information about this problem?