efc_linux compiler problem on tx01 machine with ropp_1dvar: /ropp_1dvar/math/matrix/matrix.f90

[Michael Rennie]

Error 162 at (510:../math/matrix/matrix.f90) : This expression must have type INTEGER

(int(sqrt(8.*size(A))+1)-1)/2)

x

After testing the efc compiler with the line: real, dimension((int(sqrt(8.*size(A))+1)-1)/2) ::B realised that the comipler itself seems to be the problem: it refuses to accept the expression as an integer, although another integer variable can be set to((int(sqrt(8.*size(A))+1)-1)/2) no problem. The problem is in setting the dimension. A solution would be to allocate the array size afterwards.

[Dave Offiler]

This is almost certainly an NEC compiler bug. The problem can be illustrated with the trivial example:

program problem

 integer :: i = int(1.0)

 print*,i

end program problem

which gives:

bash-2.05$ efc -o problem problem.f90
   program PROBLEM
 integer :: i = int(1.0)
                    ^
Error 162 at (3:problem.f90) : This expression must have type INTEGER

compilation aborted for problem.f90 (code 1)

but which compiles and runs perfectly well with all available Linux compilers. [As a check, efc is perfectly happy with i = int(1), so it clearly thinks 'int' needs an integer argument in this situation!]

This bug should be reported via a Remedy INC.

A possible work-around is to replace the generic 'int' intrinsic in the orginal matrix.f90 code with the specific 'ifix' since we are configuring with 'efc -i4' to force use of default 4-byte integers on the NEC, and 4-byte ints are default elsewhere . IFIX might break if using 8-byte integers, e.g. on SX8 (which probably doesn't have the efc bug - not tested).

This change also needs to be applied to matrix_sqrt.f90, solve.f90 and solve_pos.f90 and then allows ropp_1dvar to be fully built on tx01. Futher testing required to check everyting still compiles on other platform/compiler combos and the code actually runs and generates the expected array sizes.

[Dave Offiler]

Reported via Remedy INC203071

Further tests show that for NAG (f95) on both Linux & HP-UX:

$ f95 -o problem problem.f90
Error: problem.f90, line 3: INT of non-integer not permitted in an initialisation expression
Errors in declarations, no further processing for PROBLEM
[f95 error termination]

suggesting usage of INT() in this situation may be a grey area in the F95 standard, unless NAG is buggy as well.

And changing INT() to IFIX() in this trivial example breaks ifc as well as f95, though all compilers on Desktop Linux (and efc) work with IFIX() in the array dimension context of the original problem code (as a simple example - to be tested in full ROPP).

[marq]

I've looked this up in the Intel v9.0 documentation - IFIX simply is another name for INT with REAL(4) arguments. From that point of view I see no reason to change it. From the same documentation, INT is the generic interface allowing all type of integer, real and complex arguments, so its way more general. If efc doesn't work, it's a bug in that compiler. What version are you using? Is this the most recent?

I'm also concerned that applying the fix in your sample breaks other compilers. This should never happen for a proper workaround, and suggests that reverting the change actually would be a preferrable option. In general, I would like to have ROPP being standard compliant, not a collection of workarounds for compiler bugs - and especially not for a single compiler on a single machine. For the time being, I'll therefore will not propragate this "fix" upstream into the matrix class of math90 - which means it might be overwritten by the next update of this class. Please be aware of this possibility.

A better to handle this (i.e., workarounds for specific compilers) in general is to provide dedicated implementations for these compilers and use the compiler detection mechanism in the autoconf / automake to use the dedicated versions. This would make clear that a fix is required for one specific compiler explicitely, and also reduce the risk of breaking other ones. In this particular case, where the workaround is required for one compiler on one machine (if I understand correctly, the fix isn't required for the other NEC frontend), I would even go for a patch that is version controlled alongside with the ROPP - but I would not want to put such workarounds into a distributed piece of software.

[Dave Offiler]

My proposal for 'IFIX' was noted not to be a proper solution, since IFIX is specific to 4-byte integers while INT is generic. Use of IFIX would likely break 8-byte integer compiles. The code was modified thus to prove the point that the NEC compiler was broken, and as a purely temporary fix (sorry!) see if the rest of the code could be compiled (it could).

The code in question has since been reverted to the 'INT' form. (This is a clear case of a compiler bug, so I agree should not be programmed-around).

Super Compter Support have recently installed a new efc compiler (V5.4) on the tx machines - the problem efc was was ancient (v3.3), and have closed the reported INC, claimin V5.4 cures the bug.

I have just tested this claim, with the following results:

1) This compiler is not default, and needs some set up before use (e.g. in the user's .profile or in the ropp login script invoked by the IDL test system:

$ . prg_360 $ module load ipe/5.4

An 'efc -V' should confirm that v5.4 is being used.

2) Running the original trivial 'program problem' with 'int' back in place shows the compiler no longer generates an error.

3) A futher simple program with the more complex calculation:

interface prob1

     function problem(A) result(x)
       real, dimension(:),                intent(in)  :: A
       real, dimension((ifix(sqrt(8.*size(A))+1)-1)/2) :: x
     end function problem

end interface prob1

end

also compiles OK. The above example closely matched the code in matrix.f90.

Awaiting Mike's testing to confirm the issue is resolved before closing this ticket (there are currently some errors being thrown up in ropp_io/ncdf/is_netcdf.f90 which need to be fixed first)

[Dave Offiler]

Closing this particular ticket; the new efc version has cleared the original compiler bug.