Status/problems with parameterised derived types

[Simon_C]

(Apologies, but I think I put this in the wrong forum a couple of days go)

Everyone,

I wonder if some of the black belts, especially Intel employees, would like to comment on this.

I find derived types, especially parameterised derived types, extremely useful. I'm working to
finish some demo software for the middle of next month and it includes many of these structures.
The program is large (many tens of thousands of lines, though that includes comments and blank lines).

I've been told that, while derived types are not hard to understand, they are difficult to implement in  
compilers. I wish I'd known that! The experience with my program has been this:

gfortran - I don't usually use this, but gave it a try. It has a bug(s) in it's implementation of parameterised derived types.

NAG - they too have bug(s), but they have fixed the one that affected me, and my code now runs.

Intel - I've been stopped by a bug here, and a computer scientist at another institution says it is very probably the
same as one he has reported (but which hasn't been fixed).

The simple description of what I encountered is "we have assignment of an allocated array where the memory
location of the contents ends up overlapping a later allocation of the same derived type."

Are these problems widespread? Are they receiving the attention they deserve? All helpful comments welcome.

I have the simple example codes submitted by my colleague in his bug report, and have posted one below, if anyone is interested. We decided that it wasn't worth doing the same with my program (ie, trying to condense it to a simple example) until the reported bug was fixed and I'd run the updated compiler on my code. This problem has proved very costly.

Thanks,

Simon.

  implicit none

  type :: t(n)
     integer, len :: n=1
     integer x(n)
  end type t

  type(t(:)), allocatable :: x1(:), x2(:)

  allocate(t :: x1(1))
  x1(1)%x=0
  x2 = x1
  x2 = x1

  x1(1)%x = 2
  if (x2(1)%x(1).eq.2) ERROR STOP 'Such sadness'

end program

[Steve_Lionel]

It is true that PDTs. especially those with length parameters, have been the bane of compiler developers everywhere. Of the compilers you're likely to use, Intel has the most experience with them and many issues have been fixed over the years.

Your colleague's program uses some of the most obscure aspects of PDTs, with deferred length parameters, allocation with deferred type parameters, and allocation on assignment with type copying. To be honest, this is the first time I have seen this combination of features. What is really interesting here is that it's the second assignment to x2 that messes things up, causing x2(1)%x to have the same location as x1(1)%x. This is an error in how the descriptors get copied. If you omit the second assignment, it works.

If you have reported the bug to Intel, it will get fixed.

[Simon_C]

Steve,

Thank you for your reply. My reasons for having code very like that of the example is that it is an efficient and simple way to return the results of a set of calculations (in x1). They are then copied to another PDT (x2) so that the results of the next set of calculations (again returned in x1) can be compared with and combined with the first. The corruption occurs in my equivalent of x2 when new values are assigned to x1.

The various sizes and lengths - of the PDT itself and its components - aren't known until after the program starts, but then this is very often true of all kinds of arrays in all kinds of programs.

I realise that this isn't the forum to discuss software support, but my colleague reports that he has 11 open issues around PDTs and the one above was raised in September of last year. His inclination is to recommend that PDTs not be used for serious work while this situation continues. A statement from Intel would be very helpful at this point, to explain what will be done to address these problems and on what timescale.

Simon.

[Steve_Lionel]

From experience, you're unlikely to get such a statement. This is really no different from any other software product vendor. Also from experience, since I was on the support side for decades, what might help is adding to your issue submission a statement of importance or urgency. I'll observe, though, that the developers will weigh this against the probability that other users will encounter this problem and what workarounds are possible. 

It might be that if a developer takes a quick look at the issue they may find the solution to be simple and expedite the fix. That the bug requires two assignments to trigger is really strange, and may point the way to the problem. The key is getting someone's attention to take that look, when they likely have a list of other issues competing for attention. It would be nice if there were infinite resources to handle such things, but such is not the case.

[FortranFan]

@Simon Clegg,

See a few previous threads on this forum:

https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/542412

https://software.intel.com/zh-cn/forums/intel-fortran-compiler/topic/596407

https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/585069

As I had posted over 4 years ago, my own view then matched your assessment in the original post in this thread, "I find derived types, especially parameterised derived types, extremely useful.".

But things didn't pan out for me all that well with PDTs though, yet I remain a big "fan" of the feature in the Fortran language.

Intel did fix a lot of the issues with PDTs I had reported (see above threads) but some remained pending and eventually I couldn't keep track of them, especially when Intel stopped providing defect resolution summary with new compiler releases.

At the time, the team I was working with was looking at certain new computational libraries for a business application and I thought Fortran PDTs would be useful for the needs.  Alas, the compiler issues with PDT implementation in Intel Fortran proved too defective, moreover code optimization was either missing or inadequate, and the turnaround time with defect resolution in Intel Fortran was much, much longer than the duration of the entire project with this team.  The team eventually moved on to other computational specialists who were experts in designing library solutions using modern C++ (both native Windows as well as Microsoft's managed C++ layer) in conjunction with some threading and some Task Parallel libraries in .NET for concurrent evaluations.  In the base DLLs, C++ STL containers and some other libraries (Boost perhaps, I could never get details) more than allowed what they could have "home brewed" with Fortran PDTs.  They claimed success with their project and never looked back at Fortran again,  From what I hear, their eventual non-Fortran solution is still in use, it's multi-threaded, it now has RESTful APIs. and runs concurrently on a cloud platform.

[FortranFan]

For whatever it's worth and in case you were unaware: defined assignment allows you to workaround your problem.  Note the module m in the code below with the lines marked A and B and the 2 attempts with either A or B commented out.

C:\Temp>type p.f90
  module m

   type :: t(n)
      integer, len :: n=1
      integer x(n)
   end type t

   generic :: assignment(=) => assign_vector

contains

   subroutine assign_vector( lhs, rhs )

      type(t(n=:)), allocatable, intent(out) :: lhs(:)
      type(t(n=*)), intent(in)               :: rhs(:)

      allocate( lhs, source=rhs )

   end subroutine

end module

   use m, only : t  !<-- A
   !use m           !<-- B

   type(t(:)), allocatable :: x1(:), x2(:)

   allocate(t :: x1(1))
   x1(1)%x = 0
   x2 = x1
   x2 = x1

   x1(1)%x = 2
   if (x2(1)%x(1).eq.2) ERROR STOP 'Such sadness'

   print *, "x1(1)%x = ", x1(1)%x
   print *, "x2(1)%x = ", x2(1)%x

end program

C:\Temp>ifort /standard-semantics /warn:all /stand:f18 p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.166 Build 20191121
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.24.28316.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\Temp>p.exe
Such sadness

C:\Temp>type p.f90
  module m

   type :: t(n)
      integer, len :: n=1
      integer x(n)
   end type t

   generic :: assignment(=) => assign_vector

contains

   subroutine assign_vector( lhs, rhs )

      type(t(n=:)), allocatable, intent(out) :: lhs(:)
      type(t(n=*)), intent(in)               :: rhs(:)

      allocate( lhs, source=rhs )

   end subroutine

end module

   !use m, only : t  !<-- A
   use m           !<-- B

   type(t(:)), allocatable :: x1(:), x2(:)

   allocate(t :: x1(1))
   x1(1)%x = 0
   x2 = x1
   x2 = x1

   x1(1)%x = 2
   if (x2(1)%x(1).eq.2) ERROR STOP 'Such sadness'

   print *, "x1(1)%x = ", x1(1)%x
   print *, "x2(1)%x = ", x2(1)%x

end program

C:\Temp>ifort /standard-semantics /warn:all /stand:f18 p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.1.0.166 Build 20191121
Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.24.28316.0
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\Temp>p.exe
 x1(1)%x =  2
 x2(1)%x =  0

C:\Temp>

[Simon_C]

3 months later....

Thank you everyone for your helpful contributions. After arguing my case as best I could through the usual support channel, and trying to apply other pressure (via the company contacts of a supplier) to fix the PDT bugs, this is where we are as I understand it: "Most of the fixes will be available in the next Update 2 to 19.1 Compiler (part of Parallel Studio XE 2020 Update 2)". I have a list of the reference numbers and brief descriptions of the bugs, if anyone is interested. The statement in italics refers specifically to the Windows compiler. (I also use the Linux one, but haven't enquired about that.)

The news is not all good, though. Version 19.1 of the compiler requires Windows 10. The portable that I am using to work at home on, and which I travel with, is Windows 7. Intel has declined to apply the fixes to the last Windows 7 version of the compiler, even though it is still officially supported. Instead, my two compiler licences were extended by a year. This was not my preferred outcome, and you should draw your own conclusions from that.

[andrew_4619]

Intel has declined to apply the fixes to the last Windows 7 version of the compiler, even though it is still officially supported. 

W7 is obsolete with Microsoft. "Mainstream support ended on January 13, 2015. Extended support ended on January 14, 2020.". I am not sure it is reasonable to expect support for W7 IMO>

Good news on the other fixes.

[Steve_Lionel · Accepted solution]

Have you tried installing 19.1 on W7? Based on my past experience, as long as a supported VS is there it should work. But that last may give you problems as well, as the versions of VS that 19.1 supports aren't supported on W7 and may not install there.

Intel doesn't retrofit fixes to older compiler versions, except in unusual circumstances relating to security issues (such as the various CPU side-channel attacks), and even then it tends to be for C++ only. This is a fairly common practice in the industry. That an old version is "supported" only means that they'll accept support requests about it, not that fixes will be backported.

[Simon_C]

Thankyou Steve, this is the first time the 19.1 + Win 7 issue has been explained to me. Previously, I had only been told it "might work" which wasn't enough for me to try it. Both VS 2019 and 2017 have Win 7 SP 1 in their lists of system requirements on the Microsoft site, so I ought to be able to install and run them on my Win 7 machine. Both, in their appropriate versions, also appear to work with compiler v19.1 according to the Intel documentation on the subject, as I read it, although this conclusion doesn't seem consistent with what you have written in your first sentence. This is useful to know, though.

(https://software.intel.com/content/www/us/en/develop/articles/intel-compilers-integration-support-for-microsoft-visual-studio-2017.html)

[Steve_Lionel]

I was not aware that VS2019 and 2017 still recognized W7. If so, that helps a lot.

[Barbara_P_Intel]

Regarding which Windows versions are supported, see the Fortran Release Notes for Windows, System Requirements.