comparing derived types in fortran

Question

I was trying to compile a project which solves the Navier-Stokes on a sphere available here: https://fms.gfdl.noaa.gov/gf/

the default compiler used is ifort, and I wanted to use gfortran, since I want to make it finally available to whoever wishes to use it.

at some points in the code, there are statements like

if (x == y)

,where x and y are both derived types (called domain1d/2d) containing integers, reals and pointers. gfortran complains saying that the comparison is between non numbers and quits.

I then downloaded a trial version of ifort and it compiled without issues.

So, I wanted to know whether this is some kind of ifort shorthand to actual comparison of each member of the type/structure (im more comfortable with the C terminology!) or whether im missing something fundamental, being new to fortran?

I understand comparing derived types makes little sense sometimes, but here it simply seems to be checking whether both carry the same information.

Thanks, Joy

What's the TYPE // END TYPE definition for these variables? It doesn't seem evident to me that you can do logical tests on derived types, but I really don't know. — Richard Wеrеzaк
The Intel Fortran compiler implements all sorts of extensions to the Fortran standards, some inherited from its ancestors (such as DEC Fortran). It wouldn't surprise me to learn that it implements equality testing for derived types, it wouldn't surprise me to learn that it compiles such a statement but doesn't properly implement what we might think it ought to. You can probably smoke out the issue with ifort if you set the compiler options for strict adherence to the language standards. — High Performance Mark
the definition looks something like this: `type domain1D private type(domain_axis_spec) :: compute, data, global logical :: cyclic type(domain1D), pointer :: list(:) =>NULL() integer :: pe !PE to which this domain is assigned integer :: pos !position of this PE within link !list, i.e domain%list(pos)%pe = pe end type domain1D ' — Joy Monteiro
I tried running ifort with -stand f03 (and f95), and it did not complain again! I think i will write a small program using some simple derived type and check what it actually is doing. — Joy Monteiro

David Wells David Wells · Accepted Answer · 2013-07-03T14:16:18

Richard W is correct. I encountered a similar problem with an atmospheric code from NOAA. This is a bug in older versions of GCC (it affected me in 4.47 and not in 4.8). For some reason, overloading .EQ. does not overload == and vice versa (if you look at the implementation of domain1D, it definitely overloads .EQ. and then == shows up somewhere else in the code). I solved the problem by ensuring that either .EQ. or == was used throughout.

To the best of my knowledge, .EQ. and == should be equivalent (I haven't looked that hard at the standard) which is why ifort (and in my case, the SGI Fortran compiler) did not encounter this problem.

comparing derived types in fortran

1 Answers