Compilation with Intel v14.1.106 now proceeds further than with 14.0.080, we've seen problems with this version in other applications, and now recommend that NCI users avoid it. The latest error comes from Fields_manipulation.F90:
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ALLOCATE_ELEMENT]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ALLOCATE_ELEMENT_WITH_SURFACE]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ALLOCATE_CONSTRAINTS_TYPE]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^DEALLOCATE_ELEMENT]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^DEALLOCATE_CONSTRAINTS]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^INCREF_ELEMENT_TYPE]
use elements
----^
Fields_Manipulation.F90(29): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^HAS_REFERENCES_ELEMENT_TYPE]
use elements
----^
Fields_Manipulation.F90(2330): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [DEALLOCATE]
call deallocate(shape)
---------^
Fields_Manipulation.F90(2351): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [DEALLOCATE]
call deallocate(shape)
---------^
Fields_Manipulation.F90(3591): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [INCREF]
call incref(output_mesh%faces%shape)
-----------^
I haven't had a chance to look any closer at this, so I'm afraid I can't be any more helpful. I don't believe the problem is with module ordering any more, as Rhodri experimented briefly with re-ordering without any success. I'd me more inclined to believe that changing the order of 'use' statements changing the outcome of compilation is itself a bug which appears to not be present in this compiler version.
Hi Gerard
Compilation with Intel v14.1.106 now proceeds further than with 14.0.080, we've seen problems with this version in other applications, and now recommend that NCI users avoid it. The latest error comes from Fields_ manipulation. F90:
Fields_ Manipulation. F90(29) : warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ ALLOCATE_ ELEMENT] Manipulation. F90(29) : warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ ALLOCATE_ ELEMENT_ WITH_SURFACE] Manipulation. F90(29) : warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ ALLOCATE_ CONSTRAINTS_ TYPE] Manipulation. F90(29) : warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ DEALLOCATE_ ELEMENT] Manipulation. F90(29) : warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ DEALLOCATE_ CONSTRAINTS] Manipulation. F90(29) : warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ INCREF_ ELEMENT_ TYPE] Manipulation. F90(29) : warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [ELEMENTS^ HAS_REFERENCES_ ELEMENT_ TYPE] Manipulation. F90(2330) : error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [DEALLOCATE] Manipulation. F90(2351) : error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [DEALLOCATE] Manipulation. F90(3591) : error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [INCREF] output_ mesh%faces% shape)
use elements
----^
Fields_
use elements
----^
Fields_
use elements
----^
Fields_
use elements
----^
Fields_
use elements
----^
Fields_
use elements
----^
Fields_
use elements
----^
Fields_
call deallocate(shape)
---------^
Fields_
call deallocate(shape)
---------^
Fields_
call incref(
-----------^
I haven't had a chance to look any closer at this, so I'm afraid I can't be any more helpful. I don't believe the problem is with module ordering any more, as Rhodri experimented briefly with re-ordering without any success. I'd me more inclined to believe that changing the order of 'use' statements changing the outcome of compilation is itself a bug which appears to not be present in this compiler version.