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.