search

fkloiber / googletest

Automatically exported from code.google.com/p/googletest
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Pathscale compiler also pretends to be GCC and doesn't support tr1/tuple #404

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The gtest-port.h header has this bit in it:

// We use our own TR1 tuple if we aren't sure the user has an
// implementation of it already.  At this time, GCC 4.0.0+ and MSVC
// 2010 are the only mainstream compilers that come with a TR1 tuple
// implementation.  NVIDIA's CUDA NVCC compiler pretends to be GCC by
// defining __GNUC__ and friends, but cannot compile GCC's tuple
// implementation.  MSVC 2008 (9.0) provides TR1 tuple in a 323 MB
// Feature Pack download, which we cannot assume the user has.
# if (defined(__GNUC__) && !defined(__CUDACC__) && (GTEST_GCC_VER_ >= 40000)) \
    || _MSC_VER >= 1600
#  define GTEST_USE_OWN_TR1_TUPLE 0
# else
#  define GTEST_USE_OWN_TR1_TUPLE 1
# endif

Unfortunately, when compiling with the Pathscale compiler 
(https://github.com/pathscale/path64-suite), this doesn't work, because it does 
something similar to what Cuda does.

I simply added another !defined(__PATHCC__) in there, and then it seems to work.

(There is still a problem with the compiler not recognizing -Wextra, but I'm 
not sure how to patch that out except by removing that line from 
cmake/internal_utils.cmake. I guess Cmake may be mis-identifying the compiler?)

Original issue reported on code.google.com by eva...@gmail.com on 20 Feb 2012 at 7:47

GoogleCodeExporter commented 9 years ago 
The downsides of fixing this is the increased code complexity and the fragility 
of the approach (if/when Pathscale starts supporting tuple, this code will get 
broken again). As easy workaround is available (build with 
-DGTEST_USE_OWN_TR1_TUPLE=1), it doesn't make sense to put this in.

Original comment by vladlosev on 21 Feb 2012 at 4:33