having trouble running generic linked list program

having trouble running generic linked list program

I have a small test program which creates a generic linked list.   It compiles, but doesn't run.

When I try to access the values of the link, it gets a memory error (access violation).

The values of the list are pointers to unlimited polymorphic variables.

I have attached the code.

Can you tell me what I'm doing wrong?


Downloadapplication/octet-stream generic_linklist.f90691 bytes
Downloadapplication/octet-stream link.f901.84 KB
Downloadapplication/octet-stream list_0.f902.39 KB
8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hello Terry,

I think in link.f90, instead of:

  type link
    class(*), pointer :: value => null()
    type(link), pointer :: next => null()

you should first define 'next' as:

  type link
    class(*), pointer :: value => null()
    class(link), pointer :: next => null()

Otherwise, you will have conflicting pointer type assignments at line 31 (constructor%next => next) and line 44 ( this%next => next), ie, you would attempting to assign CLASS(link) to TYPE(link).

I made that change, and the code compiled and linked, but the executable crashed at line 56 in link.f90, on the select type:

    subroutine printLink(this)
      implicit none
      class(link) :: this
      select type(v => this%value)

I don't know if this is a compiler bug or not.  I'll need to work through the traceback.  I suspect something funny about line 59:

     type is (character(*))

I think this is legal, but I'll need to look into it.

Thank you,


Hello Terry,

The access violation is due to a bug in link.f90, subroutine printLinks. 

On first entry, 'curr' is unassociated. 

If you comment out the call to printLink (as shown), the program runs normally.

    subroutine printLinks(this)
    implicit none
    class(link) :: this
    class(link), pointer :: curr

!!!    call printLink(curr)
    curr => this%next
    do while(associated(curr))
      call printLink(curr)
      curr => curr%next

With that change, things seem normal:

>ifort link.f90 list_0.f90 generic_linklist.f90 -Fe:foo.exe

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version Build 20140130
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

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



Is that the correct output?



Thanks Patrick, that did fix the problem.

However, I wanted to print the first element as well, so instead of commenting out the first call to printLink, I preceded it with curr=>this, or I could have used printLink(this).

One comment, I can't see the value variable in the debugger.  Is this because it is a unlimited polymorphic variable?

Hi Terry,

I don't know of a restriction viewing  class(*) variables in the debugger.  Could you be more specific?  For example, using VS2012, in subroutine addInteger(this, value), I set a breakpoint on the allocate statement at line 56:

allocate(v,source=value) !! line 56

With a Debug x64 configuation, I can repeatedly run to that breakpoint and see 'value' updated with every pass:
U506813.exe!LIST_MOD_mp_ADDINTEGER(TYPE(LIST) THIS={...} , INTEGER(4)  VALUE=#00000004 ) Line 56 Unknown

What do you see?



Yes, I can see the what the variable value contains, but after I allocate v, I cannot see what v contains.

Also, when I am looping through prinkLink, the debugger cannot show me the value of v or this%value.

I am using the debugger in 64 bit mode.

Thanks for looking at it.



A class(*) variable has no type on its own - you need to be within a SELECT TYPE construct and then a new "copy" of the variable will be visible in the debugger and you can see its contents as if it were the selected type.

Retired 12/31/2016

Hi Terry,

Thanks for the feedback.  Right, I can't see the value of the associate-name variable (ie, the 'v') nor the value of this%value in PrintLink().  You might have run into a limitation of the Fortran Expression Evaluator (FEE).  I'll ask the developers.


Leave a Comment

Please sign in to add a comment. Not a member? Join today