[petsc-dev] C++ and hypre long long int vs PETSc int64_t for 64 bit integer builds

[Barry Smith]

  Thanks, but this is not my package. It is AMReX, I'm sure they won't have a problem with different tests but they may have problems with "still need some casts depending on usage".

  Barry


> On Apr 13, 2022, at 10:13 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> 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 <bsmith at 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