zfp Fortran compilation problem with flang (AMD aocc 2.2.0)

[mfvalin]

zfp.f contains code sequences like integer, parameter :: const_zFORp_version_major = 0 integer, parameter :: const_zFORp_version_minor = 5 integer, parameter :: const_zFORp_version_patch = 5 integer, protected, bind(c, name="zFORp_version_major") :: zFORp_version_major integer, protected, bind(c, name="zFORp_version_minor") :: zFORp_version_minor integer, protected, bind(c, name="zFORp_version_patch") :: zFORp_version_patch data zFORp_version_major/const_zFORp_version_major/, & zFORp_version_minor/const_zFORp_version_minor/, & zFORp_version_patch/const_zFORp_version_patch/

that create a compilation problem for the flang (aocc 2.2.0) compiler inducing messages like F90-W-0164-Overlapping data initializations of zforp_version_minor ...

the appropriate symbols also seem to be misisng from zfp.o

this looks like a compiler problem, as a workaround, i suppressed the bind(c, ....) clauses for initialized variables to be able to use zfp with that Fortran compiler the zfp fortran test seems to work properly

i have sent email to AMD with a reduced version of the problem to show it in a simple case module demo integer, parameter :: const_zFORp_version_major = 0 integer, parameter :: const_zFORp_version_minor = 5 integer, parameter :: const_zFORp_version_patch = 5 integer, protected, bind(c, name="zFORp_version_major") :: zFORp_version_major = const_zFORp_version_major integer, protected, bind(c, name="zFORp_version_minor") :: zFORp_version_minor = const_zFORp_version_minor integer, protected, bind(c, name="zFORp_version_patch") :: zFORp_version_patch = const_zFORp_version_patch end module is enough to make flang protest

[lindstro]

@mfvalin Thanks for reporting this issue. Not being a Fortran programmer myself, it's unclear to me if adopting this change is "safe" or if it could create issues with other Fortran compilers. If it's truly a compiler bug, then I would prefer that this be addressed in flang. I'd appreciate if you would follow up with AMD's response so we can work toward a resolution.

Regarding the zfp Fortran test, it's quite rudimentary and little more than a sanity check. We recognize the lack of Fortran tests as a major gap that needs filling, but with zfp's several thousand unit tests, porting the tests to Fortran is a significant effort. We have been working with the LLNL Rose team to automate code generation of Fortran tests by piggybacking onto the cmocka tests. Rewriting these tests from scratch is just something our team does not have cycles for (or expertise) at the moment.