error #6463 This is not a derived type name

error #6463 This is not a derived type name


I'm new to Fortran 2003 (and above) OOP in fortran (although pretty exprienced with Java, C++, etc OOP) and have started out with a basic linked list program to understand how the new standards allow for OOP inheritance, polymorphism, etc. Unfortunately, I can't get it to compile because of a "error #6463: This is not a derived type name" error. I found a related article ( that says the problem should have been fixed with Update 7 (2011.1.1.256 - Linux). I'm using 2011_sp1.9.293 and am still getting the error. I assume it is related to the overloaded constructor in the link module having the same name as the datatype. Changing the overloaded constructor to something like 'new' allows me to compile link.f90 and list.f90, but then it fails in main.f90. Anyway, I've attached the original link.f90, list.f90 and main.f90 to see if I'm missing something. The compile options I use are:

ifort -c link.f90
ifort -c list.f90
ifort -c main.f90

And then link the .o files. Unfortunately, I haven't been able to get past linking list.f90.

I've also attached a modified link_new.f90, list_new.f90, which re-name the constructor and compile, but when I attempt to compile the main.f90, I get a "main.f90(7): error #6404: This name does not have a type, and must have an explicit type. [#UNLPOLY]", which I assume is because the definition of the my_list variable doesn't know how to create the type because link is no longer overloaded to new.

Any help would be appreciated.



8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I don't see that you're doing anything wrong - you've run into some compiler bugs. I think these are being worked on, but I will verify that. Sorry for the inconvenience. A workaround is to remove the PRIVATE statements for your "new" version. It doesn't help the original.

Retired 12/31/2016

First case is a previously reported problem, issue ID DPD200179235. It occurs when a type and generic interface have the same name and then the type is referenced in another module's derived type declaration along with POINTER. It is not yet fixed.

Second case is also a previously reported problem, issue ID DPD200175597, with the same source. This one has been fixed for a future release.

Retired 12/31/2016

Thanks for the update. There was some mention of a fix as of revision 7 so I just wanted to make sure that I wasn't missing something.


Yes, but that fix was for a different combination of features.

Retired 12/31/2016

Dear Steve,

I also ran into the same problems (I guess we were all learning F2003 and copied from the same source on the internet). By commenting out the "interface link" segment and made a few changes here and there I was able to get through to the issue with "main". But no idea what the other [#UNLPOLY] error was talking about. Hopefully the fix is coming soon. :)

my version is:
$ ifort --version
ifort (IFORT) 12.1.4 20120410
Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

The error message is:
list.f90(183): error #6404: This name does not have a type, and must have an explicit type. [#UNLPOLY]
do i=1,10
list.f90(192): catastrophic error: Internal Compiler Error: possible out of order or missing USE

The #UNPOLY is an internal identifier which should never appear in an error message... Would you please attach the source you are using where you see that?

Retired 12/31/2016

Both issues from the original post were fixed in the 13.0 compiler.

Retired 12/31/2016

Leave a Comment

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