Compilation fails with BOZ literal constant

[davidpfister]

Description

I am trying to compile a code performing some SHA1 hashing. The code contains the following data

data(h0_ref(i), i=1, 5) / &
            z'67452301', &
            z'EFCDAB89', &
            z'98BADCFE', &
            z'10325476', &
            z'C3D2E1F0'/

when compiling with fpm using fpm build I get the following message

Error: BOZ literal constant at (1) is neither a DATA statement value nor an actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram [see '-fno-allow-invalid-boz']
compilation terminated due to -fmax-errors=1.
<ERROR> Compilation failed for object " src_SHA1.f90.o "
<ERROR> stopping due to failed compilation
STOP 1

I manage to compile my code if I pass the proposed flag option build --flag "-fallow-invalid-boz". However, there is a difference with ifort which compiles the same code without any problem and without specifying any additional flag.

Expected Behaviour

The code should compile with gfortran without passing additional flags just like it does with ifort

Version of fpm

0.10

Platform and Architecture

Windows

Additional Information

No response

[ivan-pi]

Which version of gfortran were you using?

I don't see any problem starting with gfortran 10: https://godbolt.org/z/a7Wzrfj1x.

In either case, I see this as a compiler issue, not an fpm one.

Details around the usage of BOZ constants were standardized in recent Fortran versions, see https://stevelionel.com/drfortran/2020/08/11/doctor-fortran-in-were-all-bozos-on-this-bus/

[davidpfister]

@ivan-pi, I am using gfortran 14. And actually, gfortran can compile the code provided that I add the argument '-fallow-invalid-boz' (which may even be present by default).
So there is no bug issue here, it's more that there is a discrepancy between compilers coming from default options that are used (or not) in fpm. fpm seems to enforce -fno-allow-invalid-boz for gfortran, but not the equivalent option (if it exists) for ifort.

[ivan-pi]

It looks like some handling was added for the MPI packages, but I don't see it being applied generally.

fpm/src/fpm_meta.f90

Lines 751 to 761 in 1ae7351

	allow_BOZ: if (compiler%id==id_gcc) then
	call new_version(ver10,'10.0.0',error)
	if (allocated(error)) return
	if (ver>=ver10) then
	this%has_build_flags = .true.
	this%flags = string_t(' -fallow-invalid-boz')
	end if
	endif allow_BOZ

I created a new fpm project, and added the following to app/main.f90

subroutine test
implicit none
integer :: h0_ref(5)
integer :: i

data (h0_ref(i), i=1, 5) / &
            z'67452301', &
            z'EFCDAB89', &
            z'98BADCFE', &
            z'10325476', &
            z'C3D2E1F0'/

print *, h0_ref

end subroutine

interface
  subroutine test
  end subroutine
end interface

call test
end

It builds without extra flags needed in fpm 0.11.0,

$ FPM_FC=gfortran fpm run
[  0%]                       main.f90
[ 50%]                       main.f90  done.
[ 50%]                            sm3
[100%]                            sm3  done.
[100%] Project compiled successfully.
  1732584193  -271733879 -1732584194   271733878 -1009589776
$ FPM_FC=ifort fpm run
[  0%]                       main.f90
[ 50%]                       main.f90  done.
[ 50%]                            sm3
[100%]                            sm3  done.
[100%] Project compiled successfully.
  1732584193  -271733879 -1732584194   271733878 -1009589776

Maybe you can share a different reproducer?

[davidpfister]

While working on a reproducer, it seems that I got misled by the error message. The problem is not in the data declaration, but one line later in an implicit type casting

module boz
   
    implicit none; private

contains

    subroutine sha1b()
        integer :: k

        k = z'6ED9EBA1'
    end subroutine
end module

Adding the explicit int(...), works fine in this case.
But the discrepancy between compilers remains. The implicit casting is not standard compliant I guess?

[ivan-pi]

But the discrepancy between compilers remains. The implicit casting is not standard compliant I guess?

The interpretation of BOZ constants was clarified in F2008 (see Steve Lionel's blog). You need to use,

        k = int(z'6ED9EBA1')

to make it standard-conforming or add the -fallow-invalid-boz switch in case of gfortran.

IMO this is not an issue fpm should fix.

Just for the record, here's what NAG Fortran shows for this case:

(base) di75yas@login03:~/dispatch_test> nf -c boz.f90 
NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7203
Questionable: boz.f90, line 7: Variable K set but never referenced
Extension(NAG): boz.f90, line 6: BOZ constant outside DATA/INT/REAL/DBLE/CMPLX
[NAG Fortran Compiler normal termination, 2 warnings]

If I add -Error=Extension, then the use of the BOZ constant is promoted to an error. If I add int() the extension warning goes away.

[davidpfister]

I tend to agree. Seems that ifort is quite permissive with that. Is there an option to pass to ifort to enforce a behavior similar to gfortran and nag?

[davidpfister]

I guess it has not been fixed after all 😆