Building Trilinos with Kokkos enabled doesn't work on 32-bit machines #82
Comments
|
Compiler appears to be GCC 4.6.3, must have at least 4.7.2. From: Barry Smith <[email protected]mailto:[email protected]> The PETSc ./configure --download-trilinos=1 --with-cxx-dialect=C++11 --download-boost=1 --download-cmake=1 is failing on one of our machines with error message: In file included from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_Atomic.hpp:208:0, Full output from configure/build is attached configure.txthttps://github.com/trilinos/Trilinos/files/95073/configure.txt Barry Reply to this email directly or view it on GitHubhttps://github.com//issues/82. |
Then you are damn well obligated to have your Cmake code check the compiler version and verify that it is good enough! You cannot have these errors pop up at make time when they should be checked at Cmake time.
|
|
from configure.log Executing: mpicxx --version Will check with 4.9.0 |
|
Also Jason's build is on a 32bit machine. Another variable to check.. from configure.log |
|
I have a successful build with gcc-4.8.0 and 4.9.0 on linux64 [also with 5.3.1on a different linux64 box] - so I suspect its a code issue on 32bit builds.. I'm attempting a build with gcc-4.8.4 on a different linux32 box. Will see how that goes.. |
|
Newer versions of CMake (2.8.11+) supports giving you the compiler version for C and C++. See: https://cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_LANG_COMPILER_VERSION In fact, TriBITS already was printing this, for example on my machine: ... Just put in something like the following in your kokkos/CMakeLists.txt file: IF (CMAKE_C_COMPILER_ID STREQUAL "GNU" AND Cheers, -Ross
|
|
For me the error looks like a real bug in Kokkos with respect to 32bit machines. Unfortunately 32bit is not anywhere in either our Kokkos standalone testing suite (which otherwise is pretty comprehensive including more than 10 compilers) nor in the Trilinos testing environment. That means we don't catch those errors. The interesting question for Trilinos is whether we have/keep a promise to work on 32 bit. |
|
The CMake logic thing for checking compiler is interesting I didn't know that that was added. I believe we require 2.8.11 anyway, so we can add that part - but as I said I don't believe its the problem in this case. |
|
There is certainly a lot less interest in 32-bit (global ordinal) types from our main users. 32-bit local ordinals are still very important and have significant performance impact. We have decided not to permit int global ordinals for our explicit template instantiation builds, but there are still instances where you can argue for 32. No matter what, we should give clear error messages if we are not going to support it. Note from @trilinos/tpetra developer Mark Hoemmen: Above is not accurate; please refer to my comment below. |
|
TriBITS requires CMake 2.8.11+ so it is safe to put in the exact logic I gave (just make sure you test it first). |
|
This is not types, mike this is the build type (do you build for a 32 bit machine or a 64 bit machine) which affects things like size of pointer, or size of long. |
|
Sorry, I missed that. Wow, I don't see us needing to support 32-bit pointers. |
|
The thing is we have to do either or: either we support 32 bit systems, and then we have to somehow get tests for that set up, or we should fatal error when configuring for 32 bit. Myself I would be more happy with the latter, since that means one less headache for me. But that is probably a discussion for the leadership phone call on Thursday. |
|
Need a configure test with 'static_assert( sizeof(void*) == 8 )' From: Mike Heroux <[email protected]mailto:[email protected]> Sorry, I missed that. Wow, I don't see us needing to support 32-bit pointers. Reply to this email directly or view it on GitHubhttps://github.com//issues/82#issuecomment-172688595. |
|
I have added it as an item to the leaders agenda for Thursday. |
|
I am fine with not having support in xSDK for 32 bit builds, just let me know what you decide and we can document it in the xSDK google doc. I also apologize for using damn in my bug report. I should have just properly stated I recommend adding a cmake/configure test for this requirement instead of trying to be colorful but instead just being stupid. Barry
|
|
@maherou wrote: "We have decided not to permit int global ordinals for our explicit template instantiation builds..." That is not accurate. Making it possible to disable |
|
OK. Let's get to an accurate statement. It is my understanding that, once the issues related to turning off GlobalOrdinal = int (which includes issues in Sierra as well as Trilinos, and probably other apps too), we will not include GlobalOrdinal = int in the default list of ETI types. Is this a true statement? If not, please rephrase to make it correct. I want to make sure I understand the plans for this.
|
|
@maherou Hi Mike! Hope I'm not leading this thread on a tangent. The current plan is to make sure that Sierra and possibly other apps can turn off In particular, support for Epetra in Xpetra (and its dependencies, like MueLu and Zoltan2) and Amesos2 depends on Thus, we haven't committed to changing the default setting. I favor the capability of turning it off and have invested significant personal and social effort in making this work. Many other Trilinos developers have put a lot of work into this. We are working with Mike Glass on this actively (I've been answering a lot of e-mails from him over the past few days). However, changing the default setting isn't for me to decide, given the effort it would take. To summarize: It's possible now to turn off |
|
Guys this problem has nothing to do with the Global or Local ordinal size. This is a 32 bit build type vs 64 build type (as in 32 bit machine vs 64 bit machine) |
|
We've changed the PETSc build for Trilinos to error out with a very useful message if someone attempts a PETSc build with Trilinos and 32 bit pointers. Hence you will not get error reports like this in the future. Barry
|
mhoemmen
changed the title
|
I changed the bug title to reflect the actual issue. |
|
This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity. |
github-actions
bot
added
the
MARKED_FOR_CLOSURE
|
This issue was closed due to inactivity for 395 days. |
github-actions
bot
added
the
CLOSED_DUE_TO_INACTIVITY
The PETSc ./configure --download-trilinos=1 --with-cxx-dialect=C++11 --download-boost=1 --download-cmake=1
is failing on one of our machines with error message:
In file included from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_Atomic.hpp:208:0,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:50:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp: In instantiation of ‘T Kokkos::Impl::atomic_fetch_oper(const Oper&, volatile T_, typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type) [with Oper = Kokkos::Impl::AndOper<long long unsigned int, const long long unsigned int>; T = long long unsigned int; typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type = const long long unsigned int]’:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:296:69: required from ‘T Kokkos::atomic_fetch_and(volatile T_, T) [with T = long long unsigned int]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:211:64: required from ‘bool Kokkos::Impl::{anonymous}::Bitset::reset(int) [with int NumBlocks = 15]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:296:30: required from here
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3: note: template T Kokkos::atomic_compare_exchange(volatile T_, T, typename Kokkos::Impl::enable_if<((sizeof (T) != 4) && (sizeof (T) != 8)), const T>::type&)
T atomic_compare_exchange( volatile T * const dest , const T compare ,
^
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3: note: template argument deduction/substitution failed:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp: In substitution of ‘template T Kokkos::atomic_compare_exchange(volatile T_, T, typename Kokkos::Impl::enable_if<((sizeof (T) != 4) && (sizeof (T) != 8)), const T>::type&) [with T = long long unsigned int]’:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:144:103: required from ‘T Kokkos::Impl::atomic_fetch_oper(const Oper&, volatile T_, typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type) [with Oper = Kokkos::Impl::AndOper<long long unsigned int, const long long unsigned int>; T = long long unsigned int; typename Kokkos::Impl::enable_if<((sizeof (T) != sizeof (int)) && (sizeof (T) == sizeof (long long unsigned int))), const T>::type = const long long unsigned int]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Generic.hpp:296:69: required from ‘T Kokkos::atomic_fetch_and(volatile T_, T) [with T = long long unsigned int]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:211:64: required from ‘bool Kokkos::Impl::{anonymous}::Bitset::reset(int) [with int NumBlocks = 15]’
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:296:30: required from here
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Atomic_Compare_Exchange_Strong.hpp:207:3: error: invalid use of incomplete type ‘struct Kokkos::Impl::enable_if<false, const long long unsigned int>’
In file included from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_MemoryTraits.hpp:47:0,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_HostSpace.hpp:53,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/Kokkos_Atomic.hpp:71,
from /sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_AllocationTracker.cpp:50:
/sandbox/sarich/petsc/arch-linux2-c-debug/externalpackages/git.trilinos/packages/kokkos/core/src/impl/Kokkos_Traits.hpp:201:8: error: declaration of ‘struct Kokkos::Impl::enable_if<false, const long long unsigned int>’
struct enable_if ;
^
Full output from configure/build is attached
configure.txt
Barry
@sarich
@[email protected]
The text was updated successfully, but these errors were encountered: