This is what we currently have in PETSc, we check for sizeof and cast Il giorno mer 13 apr 2022 alle ore 17:13 Jed Brown <j...@jedbrown.org> ha scritto:
> C/C++ integer hierarchy was a mistake, with the language-specified types > overlapping and the size-specific (int64_t) being typedefs. So long is > "different" from long long even if they're both 64-bit signed integers. > > I think they should test that sizeof(HYPRE_Int) == sizeof(PetscInt), but > not that they're "the same". They might still need some casts depending on > usage. > > Barry Smith <bsm...@petsc.dev> writes: > > > For 64 bit integer builds AMReX has this test in their code > > > > CMakeFiles/amrex.dir/F_Interfaces/Base/AMReX_multifab_mod.F90.o > > > /lcrc/project/PhloughToolz/petsc/petsc-3.17.0_oneAPI_2021.4.0.3422/externalpackages/git.amrex/Src/Extern/PETSc/AMReX_PETSc.cpp(44): > error: static assertion failed with "HYPRE_Int != PetscInt" > > static_assert(std::is_same<HYPRE_Int, PetscInt>::value, "HYPRE_Int > != PetscInt"); > > > > Currently, hypre uses long lont int for 64 bit integers, PETSc > depending on what MPI and integer types are available uses int64_t but may > fall back to long long int. > > > > This means depending on configuration information the PETSc built > hypre and PETSc may or may not be compatible by the AMReX tests for C++ > code. > > > > What is the correct general fix for this three-body problem? > > > > Will the C++ code in AMReX, which presumably is > template-and-polymorphic-method-city, fail if the long long int and int64_t > are mixed and treated as the same (that is one just removes the is_same() > check)? Clearly, the easiest fix > > > > Do HYPRE and PETSc configure need to have command-line options to > allow controlling exactly the type used to ensure matching? > > > > Something else? > > > > Barry > -- Stefano