Object-oriented list example in "Modern Fortran Explained" does not work

[FortranFan]

I am unable to get the "classic" list example in Modern Fortran Explained - Michael Metcalf, John Reid and Malcolm Cohen, Oxford University Press, 2011, ISBN 978-0199601417 to work with Intel Fortran; both compiler version 14 or 2015 Beta are able to compile the code ok, but encounter run-time errors as follows:

 The initial list has 0 items.
 The list now has 1 items.
 The list now has 2 items.
 The list now has 3 items.
 The list now has 4 items.
 The first element is:  character = "hello"
 The last element is:  real =  2.250000
 After deleting the last element, the list contents are:
 Item 1: character = "hello"
 Item 2: integer =  17
 Item 3: character = "world"
forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
TestFor32.exe      00EF5958  _ANYLIST_M_mp_REM         261  TestMod.f90
TestFor32.exe      00EF39A5  _ANYLIST_M_mp_DEL         180  TestMod.f90
TestFor32.exe      00EF2309  _ANYLIST_M_mp_DEL          94  TestMod.f90
TestFor32.exe      00EF7F13  _MAIN__                    33  TestFor.f90
TestFor32.exe      00F68782  Unknown               Unknown  Unknown
TestFor32.exe      00F691DA  Unknown               Unknown  Unknown
TestFor32.exe      00F6932D  Unknown               Unknown  Unknown
kernel32.dll       7576338A  Unknown               Unknown  Unknown
ntdll.dll          76F5BF32  Unknown               Unknown  Unknown
ntdll.dll          76F5BF05  Unknown               Unknown  Unknown

Note I'm using the latest edit to the code made available kindly by Metcalf et al. at  ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90.  

It appears this was a known issue back on March 19, 2012 based on comments by Tim Price and Steve Lionel at this comp.lang.fortran forum topic: however, I don't know if a tracking incident was issued on the Intel side and if there is any way to check the status.

Can someone from Intel please provide some feedback on this example:

• Per Metcalf et al. (and who the Fortran world would regard among the leading authorities, if not the ultimate authority, on Fortran 2003 standard) consider this example to be worthy of a test case for Fortran 2003 - see here.  Does Intel agree with Metcalf et al.?  Note Metcalf indicates they have successfully tested the code with other compilers (possibly NAg compiler?).
• If yes, is this code really part of Intel's test suite?  And if so, what is the plan to get this working?
• If not, why not - is there something wrong with the code?!  Can Intel provide an alternate object-oriented list example based on Fortran 2003 that works?
• It appears with 2015 compiler version, Intel hopes to claim full Fortran 2003 compliance with phrases such as "Fortran now has complete Fortran 2003 support" in their What's New document.  If Intel feels strongly about this, it will be nice if Intel can first strive to get the compiler working with this textbook example, or offer an adequate explanation and guidance so its users are not left confused with the very basic books on Fortran.

Thanks,

[Steven_L_Intel1]

I'll take a look at this on Monday. I will comment that the ultimate reference on Fortran 2003 is in fact the Fortran standard, not Modern Fortran Explained. No knock on the authors, some of whom are standards committee members, but I have seen past cases where that book has erroneous examples. I have a more recent edition of the book and will see what its example looks like.

[TimP]

According to the web site, the downloaded version is more correct and up to date than what was published in the books.

For me, on win8.1 x64, it quits silently.

I'm more comfortable with the beta debugger on linux, where the "double free or corruption" libc error is thrown at about that point, with traceback not indicating where it came from, although single-stepping shows the failure at the first call list%print_list.

[TimP]

$ gfortran oo.f90
oo.f90:213.26:

    type is (character(*))
                          1
Error: Associate-name '__tmp_CHARACTER_0_1' at (1) is used as array
oo.f90:268.6:

  use anylist_m
      1
Fatal Error: Can't open module file 'anylist_m.mod' for reading at (1): No such
file or directory

At least gfortran recognizes impending trouble.

[FortranFan]

Steve Lionel (Intel) wrote:

.. I have a more recent edition of the book and will see what its example looks like.

Steve,

Thanks for your follow-up.  As I explained in the first post and as mentioned by Tim in Quote #3, please note the code from the ftp site ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90 is supposedly the corrected version - details are here.

And please note I'm fully open-minded on this issue; I'd simply like to learn what is going on here.  But if the expert consensus ends up being the oo.f90 code is indeed correct relative to Fortran 2003 standard, then I'd very much like Intel Fortran to support it because I really need to implement list "classes" along the lines of this example in many of my codes and I'm running into problems which seem related to what's going on with oo.90 example i.e., in Intel Fortran, there is something amiss when it comes to "deleting/clearing/finalizing" linked lists that make use of Fortran 2003 OO features such as type-bound procedures:

• Using gfortran 4.9, note the first list "class" I implemented in my actual code seems to work correctly - compiles with no errors or warnings, I get no runtime errors, and Dr Memory finds ZERO leaks.
• However with Intel Fortran, I either get runtime exceptions very similar to the above oo.f90 example or if I remove the finalizer procedure, the code runs but there are significant memory leaks.  Owing to corporate policy where I work, I can't post this case at the forum and hence I'm trying to submit an incident at the Intel Premier Support as part of compiler 2015 Beta.

[FortranFan]

Tim Prince wrote:

$ gfortran oo.f90

oo.f90:213.26:

    type is (character(*))

                          1

Error: Associate-name '__tmp_CHARACTER_0_1' at (1) is used as array

oo.f90:268.6:

  use anylist_m

      1

Fatal Error: Can't open module file 'anylist_m.mod' for reading at (1): No such

file or directory

At least gfortran recognizes impending trouble.

Tim,

I think the compiler error with gfortran 4.9 is a separate issue and identified on the gfortran bug list: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 - see Janus Weil's comment at the end of this link on 18 September 2013.

[TimP]

Yes, thanks, I see that this case was added to that gfortran bug report, which seems to affect gfortran from 4.8.0 through current trunk (4.10).

[FortranFan]

Tim Prince wrote:

Yes, thanks, I see that this case was added to that gfortran bug report, which seems to affect gfortran from 4.8.0 through current trunk (4.10).

In addition, gfortran 4.9 appears to have a separate problem with functions that return data pointers such as append and prepend in the oo.f90 example.

I stay away from functions that return data pointers, almost as a matter of principle, so my own list "class" is not affected the way oo.90 is and it runs fine with gfortran 4.9.

However, Intel Fortran, which seems to handle well functions that return data pointers, has some problem with "deleting/clearing/finalizing" the list.

[FortranFan]

FortranFan wrote:

Quote:

Steve Lionel (Intel) wrote:

.. I have a more recent edition of the book and will see what its example looks like.

Steve,

...

And please note I'm fully open-minded on this issue; I'd simply like to learn what is going on here.  ... I really need to implement list "classes" along the lines of this example in many of my codes and I'm running into problems which seem related to ... "deleting/clearing/finalizing" linked lists that make use of Fortran 2003 OO features such as type-bound procedures:

• Using gfortran 4.9, note the first list "class" I implemented in my actual code seems to work correctly - compiles with no errors or warnings, I get no runtime errors, and Dr Memory finds ZERO leaks.
• However with Intel Fortran, I either get runtime exceptions very similar to the above oo.f90 example or if I remove the finalizer procedure, the code runs but there are significant memory leaks.  Owing to corporate policy where I work, I can't post this case at the forum and hence I'm trying to submit an incident at the Intel Premier Support as part of compiler 2015 Beta.

Steve,

Fyi, an Intel Premier Support incident has been submitted with a lot of details for my list "class."  The reference number is 6000058970, if you wish to take a look.  Please note my urgent need is to get the code in the IPS incident working asap, more so than the oo.f90 example from MFE book.  However I very much think the two issues are related.  Hence I would greatly appreciate any guidance/insight you can provide in either of the cases.

Also, note my ultimate interest is in utilizing the Fortran 2008 feature of "recursive components of allocatable type" for my list "classes", but as you know, none of the Intel Fortran compiler versions supports such a feature yet.  Is it possible for you to comment whether this feature may become available any time soon?

Thanks,

[yamajun]

I met the same problem with Intel Fortran v.14.0 last autumn. I'm curious about this problem, too.

Anyway there is something wrong with SUBROUTINE DELETE. 

  !
  ! Delete an item: removes it from the list and deallocates it.
  !
  subroutine delete(item)
    class(anyitem), target  :: item
    class(anyitem), pointer :: temp
    temp => item
    call remove(item)
    deallocate (temp)
  end subroutine

 If "temp" is removed instead of "item" as below, the program runs without problem. 

  !
  ! Delete an item: removes it from the list and deallocates it.
  !
  subroutine delete(item)
    class(anyitem), intent(in), target  :: item
    class(anyitem), pointer :: temp
    temp => item
    call remove(temp)
    deallocate (temp)
  end subroutine

The cause of crash is in SUBROUTINE REMOVE (called by SUBROUTINE DELETE_LIST by way of SUBROUTINE DELETE ).

      else if (associated(list%firstptr, item)) then
        ! First item in list.
        list%firstptr => item%nextptr         ! first = next.
        item%nextptr%prevptr => item%prevptr  ! next%prev = last.
      end if
    end if
    nullify(item%upptr)

Dummy argument "item" is alias to"list%firstptr" ( actual argument of  SUBROUTINE DELETE_LIST). This means the "first = next" line "list%firstptr => item%nextptr" is the same as "item => item%nextptr".  So nullify(item%upptr), which should nullify 'first'%upptr, nullifies 'next'%upptr instead. But using "temp" as actual argument in DELETE avoids this problem. 

This is quite confusing for me and I'm not sure whether this is the correct behavior of pointers or not. 

http://fortran66.hatenablog.com/entry/2013/11/04/210236

[TimP]

Thanks it makes sense to me. No doubt Steve will consult experts next week.

[FortranFan]

Steve Lionel (Intel) wrote:

I'll take a look at this on Monday. I will comment that the ultimate reference on Fortran 2003 is in fact the Fortran standard, not Modern Fortran Explained. No knock on the authors, some of whom are standards committee members, but I have seen past cases where that book has erroneous examples. I have a more recent edition of the book and will see what its example looks like.

Steve,

Any update on the example from MFE book and how Intel Fortran treats it?  Any feedback on yamajun's comments in Quote #10 above?

Thanks,

[Steven_L_Intel1]

I started looking at this, but other things came up. I'll get back to it. I don't yet understand what the compiler is doing here - I think this example should work, but am not certain.

[Steven_L_Intel1]

I've been exchanging mail about this with John Reid and Malcolm Cohen. Malcolm is currently of the opinion that the program's method of deleting the entry is not legal, but it's still under discussion. I'm still trying to work out for myself what is going on, but John has asked me to not spend time on it until he and Malcolm work it out.

[FortranFan]

Steve Lionel (Intel) wrote:

I've been exchanging mail about this with John Reid and Malcolm Cohen. Malcolm is currently of the opinion that the program's method of deleting the entry is not legal, but it's still under discussion. I'm still trying to work out for myself what is going on, but John has asked me to not spend time on it until he and Malcolm work it out.

Thanks Steve - really looking forward to the authors' and your findings on this example.

[Steven_L_Intel1]

John Reid has sent me a revised source (which I have attached here). He and Malcolm concluded that the original example was not legal. The relevant part of the standard is 6.7.3.3, Deallocation of pointer targets, as modified by interpretation F08/0010, which adds the sentence "A pointer shall not be deallocated if its target or any subobject thereof is argument associated with a dummy argument or construct associated with an associate name."

[FortranFan]

Steve Lionel (Intel) wrote:

John Reid has sent me a revised source (which I have attached here). He and Malcolm concluded that the original example was not legal. The relevant part of the standard is 6.7.3.3, Deallocation of pointer targets, as modified by interpretation F08/0010, which adds the sentence "A pointer shall not be deallocated if its target or any subobject thereof is argument associated with a dummy argument or construct associated with an associate name."

Steve,

Thank you very much for your follow-up.  As you may have confirmed yourself, the revised code works with Intel Fortran compiler 2015 beta.  Some comments and suggestions:

1. Please take a look at the comments by the reader, yamajun, in Quote #10.  The suggestion he makes also allows the code to work with Intel Fortran, albeit with a violation of Fortran 2008 standard per F08/0010 interpretation.  Note standards checking in Intel Fortran does not catch this (/stand:f08).  Can you please review this aspect and check whether the current compiler version is expected to catch this?  If yes, then should it be treated as a bug and a tracking incident created with Intel development?  If the compiler does not yet have a capability to treat this F08 feature, then can you please consider adding this example to Intel's test (validation) cases for when the feature will be implemented?
2. The revised code you just posted in Quote #16 results in 2 "memory leak" errors and 1 "memory not deallocated" error per Intel Inspector 2015 Beta.  Can someone from Intel Fortran compiler team look at this and investigate whether the compiler can be improved if the errors are genuine?  If the errors are false positives, can someone from Intel Inspector team review and decide whether Inspector can be improved to not give such false alarms.  By the way, Dr Memory indicates 1830 bytes of possible leaks at the same locations as Intel Inspector.
3. Note the code based on suggestions by yamajun in Quote #10 only showed 1 "memory not deallocated" error.
4. Fyi, there is a thread at the comp.lang.fortran forum at the same topic: https://groups.google.com/forum/#!topic/comp.lang.fortran/aRz3HMpblTs in case you wish to add any comments there about your investigation on this matter.
5. My impression is this particular example can possibly be updated to utilize "allocatable" components instead of "pointer" components in anylist and anyitem types once the Fortran 2008 feature of "recursive components of allocatable type" becomes available in compilers.  Do you have any thoughts or comments about this?  By the way, is it possible to share whether the Fortran 2008 feature of "recursive components of allocatable type" is on the radar for an Intel compiler version in the near future?

Regards,

[Steven_L_Intel1]

Further discussion with John Reid indicates that the interpretation I quoted does not adequately address the issue and that he will be proposing a new interpretation request.

I'll look at the new example (I have not tried it yet) to see if there is a real memory leak.

All of Fortran 2008 is on our list. This particular issue is item DPD200157842.

[yamajun1]

Steve, 

Thank you for your follow-up comments.

It seems that I need to carefully read  the new OO.f90 code and the standard document.     

I could found the modified interpretation you mentioned in the technical corrigenda.

ftp://ftp.nag.co.uk/sc22wg5/N2001-N2050/N2005.pdf

Thanks,