error #8000: There is a conflict between local interface block and external interface block. [SUBSORT]

krishnabc · ‎11-11-2010

Hi,

The following segment of the code (see below) gives me "error #8000: There is a conflict between local interface block and external interface block. [SUBSORT]" and 13 other errors when compiled with Intel Visual Fortran Compiler XE 12.0.0.104 [IA-32] in Debug mode with /warn:interfaces.
However, the same code used to be compiled fine with Intel Visual Fortran 11.1.065.

Errors:

error #6633: The type of the actual argument differs from the type of the dummy argument. [CRR]

error #6633: The type of the actual argument differs from the type of the dummy argument. [1]

error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [IFIN1]

error #6634: The shape matching rules of actual arguments and dummy arguments have been violated. [IRR]

error #8284: A scalar actual argument must be passed to a scalar dummy argument unless the actual argument is of type character or is an element of an array that is neither assumed shape nor pointer. [CRR]

error #8000: There is a conflict between local interface block and external interface block. [SUBSORT]

error #6633: The type of the actual argument differs from the type of the dummy argument. [CRR]

error #6633: The type of the actual argument differs from the type of the dummy argument. [IDEB1]

error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [IFIN1]

error #6634: The shape matching rules of actual arguments and dummy arguments have been violated. [IRR]

error #7836: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argument is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [CRR]

error #6405: The same named entity from different modules and/or program units cannot be referenced. [SUBSORT]

[Note: some errors are showing repeatedly (but not by me)]

Code:

[fortran]Program Test_sort

use module_sort
implicit none

integer:: nzua
INTEGER, ALLOCATABLE :: IRR(:), JRR(:)
REAL(8), ALLOCATABLE :: CRR(:)

READ *, NZUA
ALLOCATE (IRR(NZUA), JRR(NZUA), CRR(NZUA))
READ  *, IRR
READ *, JRR
READ *, CRR

CALL QUICKSORT(NZUA,IRR,JRR,CRR)

End Program Test_sort[/fortran]

[fortran]module module_sort

contains
      SUBROUTINE QUICKSORT(NZUA,IRR,JRR,CRR)

!     THIS SUBROUTINE SORTS IRR INTO ASCENDING ORDER, JRR AND CRR CHANGE
!     CORRESPONDINGLY.

       IMPLICIT NONE

       integer:: nzua,irr(nzua),jrr(nzua) 
       real(8):: crr(nzua)
!
  
        CALL SUBSORT(IRR,JRR,CRR,1,NZUA) ;
!       CALL INSSOR(IRR,JRR,CRR,NZUA) ;
!
       RETURN
      END SUBROUTINE QUICKSORT
! -----------------------------------------------------------------------
      RECURSIVE SUBROUTINE SUBSORT(IRR,JRR,CRR, IDEB1, IFIN1)
!     THIS SUBROUTINE SORTS IRR FROM IDEB1 TO IFIN1

      IMPLICIT NONE
      INTEGER,INTENT(IN) ::  IDEB1, IFIN1 
      INTEGER :: IRR(IFIN1), JRR(IFIN1)
      REAL(8)::  CRR(IFIN1),ZWRK
      
      INTEGER :: ICRS, IDEB, IDCR, IFIN, IMIL,  &
                XPIV, XWRK, YWRK, NINS = 16  ! MAX FOR INSERTION SORT    
        IDEB = IDEB1
        IFIN = IFIN1
!     IF WE DON'T HAVE ENOUGH VALUES TO MAKE IT WORTH WHILE, WE LEAVE
!     THEM UNSORTED, AND THE FINAL INSERTION SORT WILL TAKE CARE OF THEM.
      IF((IFIN - IDEB) > NINS)THEN
         IMIL = (IDEB+IFIN) / 2
!     ONE CHOOSES A PIVOT, MEDIAN OF 1ST, LAST, AND MIDDLE VALUES
!
         IF(IRR(IMIL) < IRR(IDEB))THEN
      XWRK = IRR(IDEB) ;      YWRK=JRR(IDEB);    ZWRK=CRR(IDEB)
      IRR(IDEB) = IRR(IMIL);JRR(IDEB) = JRR(IMIL);CRR(IDEB) = CRR(IMIL)
      IRR(IMIL) = XWRK;      JRR(IMIL) = YWRK;      CRR(IMIL) = ZWRK
         END IF
!
         IF(IRR(IMIL) > IRR(IFIN))THEN
      XWRK = IRR(IFIN);       YWRK = JRR(IFIN);   ZWRK = CRR(IFIN)
      IRR(IFIN) = IRR(IMIL);JRR(IFIN) = JRR(IMIL);CRR(IFIN) = CRR(IMIL)
      IRR(IMIL) = XWRK;  JRR(IMIL) = YWRK;   CRR(IMIL) = ZWRK
            IF(IRR(IMIL) < IRR(IDEB))THEN
      XWRK = IRR(IDEB);     YWRK = JRR(IDEB);     ZWRK = CRR(IDEB)
      IRR(IDEB) = IRR(IMIL);JRR(IDEB) = JRR(IMIL);CRR(IDEB) = CRR(IMIL)
      IRR(IMIL) = XWRK;     JRR(IMIL) = YWRK;     CRR(IMIL) = ZWRK
            END IF
         END IF
         XPIV = IRR(IMIL)
!
!   ONE EXCHANGES VALUES TO PUT THOSE > PIVOT IN THE END AND
!   THOSE <= PIVOT AT THE BEGINNING
! 
         ICRS = IDEB
         IDCR = IFIN
          ECH2: DO        
            DO
               ICRS = ICRS + 1
               IF(ICRS >= IDCR)THEN
!
!  THE FIRST > PIVOT IS IDCR
!  THE LAST <= PIVOT IS ICRS-1
!  NOTE: IF ONE ARRIVES HERE ON THE FIRST ITERATION, THEN
!        THE PIVOT IS THE MAXIMUM OF THE SET, THE LAST VALUE IS EQUAL
!        TO IT, AND ONE CAN REDUCE BY ONE THE SIZE OF THE SET TO
!        PROCESS, AS IF IRR (IFIN) > XPIV
!
                  EXIT ECH2
!
               END IF
               IF(IRR(ICRS) > XPIV) EXIT
            END DO
!
            DO
               IF(IRR(IDCR) <= XPIV) EXIT
               IDCR = IDCR - 1
               IF(ICRS >= IDCR)THEN
!
!    THE LAST VALUE < PIVOT IS ALWAYS ICRS-1
!
                  EXIT ECH2
               END IF
            END DO
!
            XWRK = IRR(IDCR);      YWRK = JRR(IDCR);  ZWRK = CRR(IDCR)
            IRR(IDCR)=IRR(ICRS);JRR(IDCR)=JRR(ICRS);CRR(IDCR)=CRR(ICRS)
            IRR(ICRS)=XWRK;      JRR(ICRS)=YWRK;    CRR(ICRS)=ZWRK
         END DO ECH2         
!
!    ONE NOW SORTS EACH OF THE TWO SUB-INTERVALS
!
         CALL SUBSORT (IRR,JRR,CRR, IDEB1, ICRS-1)
         CALL SUBSORT (IRR,JRR,CRR, IDCR, IFIN1)         
      END IF
!
      RETURN
      END SUBROUTINE SUBSORT
! -----------------------------------------------------------------------
      SUBROUTINE INSSOR(IRR,JRR,CRR,NZUA)
!     THIS SUBROUTINE SORTS IRR INTO INCREASING ORDER (INSERTION SORT)

!     body of the code

      RETURN
      END SUBROUTINE INSSOR
! -----------------------------------------------------------------------

end module
! The error goes away only when I rename the subroutine "SUBSORT" to something else (e.g. SUBSORT3). So, there seems to have a naming conflict with compiler's internal program.
! Krishna














[/fortran]

krishnabc · ‎11-11-2010

Update:

I have some other recursive subroutines as wellin my big program.It is giving me the "error #8000" to all those routines one by one and compilation aborted (code 1). After renaming those routines, sometimes the error goes away and sometimes not.

Is there anything wrong in my code? I tried with assumed shape array as well but the problem persists.

Thanks.
Krishna

DavidWhite · ‎11-11-2010

Have you tried rebuilding the entire program - this will delete old object and module files.

Also, check the generate interfaces option, and possibly turn that off. Also check whether there are any old automatically generated interface module files hanging around (will be in themodules folder). Deleting these before building may help.

David

krishnabc · ‎11-11-2010

Yes, I tried by rebuilding the solution. Tried after "Cleaning" the old solution. Tried after manually "deleting" the whole Debug folder. But, the error continues to reappear.

Yes, the compilation goes fine (and works ok) with "/warn:interfaces" turned off. But, I wanted to build the project with /warn:interfaces.

anthonyrichards · ‎11-12-2010

..then it could be a compiler bug.

However, might it be worth trying

Integer IDEB1
...
IDEB1=1
CALLSUBSORT(IRR,JRR,CRR,IDEB1,NZUA)

and see what happens?

P.S. Are you compiling for 64-bit or 32-bit?

krishnabc · ‎11-12-2010

Thanks for the suggestions. Had tried that option as well, but didn't help. That's why I put a small program above, where the error can be reproduced as well. Note that when the subroutines are in module, several other errors are generated in addition to the first error #8000. However, when the subroutines are used as external routines, the compilation is aborted (code 1) after error #8000.

anthonyrichards · ‎11-12-2010

Why stop using 11.1.065 and switch to the new XE 12.0.0.104 [IA-32] ?

All new compilers are bound to be beset with bugs until we guinea pigs in the general user community put in unpaid man-years of effort to find them and bring them to the attention of the compOSER developers (what's wrong with compILER now?).

Whyswitch just because it's new when you say your program works fine with 11.1.065? Seems crazy to me and a waste of your time.

krishnabc · ‎11-12-2010

Agree with you to some extent. There is no urgency to migrate to the new XE 12.0.0.104 at the moment. However, one reason for trying XE 12.0.0.104was because it supports VS 2010 and our company is planning to buy VS 2010 in near featureand we all will be using the same. In addition, XE 12 has added F2003 features (which I may consider to use). Yes, Iwasted 2 days for this.

Steven_L_Intel1 · ‎11-12-2010

Does disabling generated interface checking make the errors go away?

krishnabc · ‎11-14-2010

If I recalled correctly, we had two options in the diagnostic page(Generate Interface Blocks and Check Routine Interfaces)in the earlier versions. I think I have usedthem before. However, now I could not find "Generate Interface Blocks" option.Is this option removed now?There is only an option for "Check Routine Interfaces", disabling of which the compilation goes fine. I havementioned this in the above post (#3).

In Code Generation page, there is an option to enable/disable Recursive Routines. However, it did not make any difference to the error.

Thanks.
Krishna

Steven_L_Intel1 · ‎11-14-2010

As of 11.1, Check Routine Interfaces implies Generate Interface Blocks, so we removed the latter from the project properties. You can still specify it manually under Command Line.

We'll take a look at the problem you reported. Thanks.

krishnabc · ‎11-14-2010

Thanks a lot - Steve.

krishnabc · ‎11-14-2010

Thanks a lot - Steve.

farchamb · ‎11-15-2010

I am having the same issue with

[bash]$ ifort --version
ifort (IFORT) 12.0.0 20101006
Copyright (C) 1985-2010 Intel Corporation.  All rights reserved.[/bash]

I had to set the flag to "-warn nointerfaces" in order to compile. I hope there will be a fix.

krishnabc · ‎12-09-2010

Dear Steve,

Just to inform you thatthe compilation now goes fine with XE 2011 update 1 with Check Routine Interfaces turned on.

Thanks everyone for their input.

Krishna