Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Help with compiler errors 6405, 10298

dajum
Novice
1,781 Views

I get these errors during compilation of my project.


C:\sf61\proces\save.f(583): error #6405: The same named entity from different modules and/or program units cannot be referenced.   [COMPL]
ifort: error #10298: problem during post processing of parallel object compilation
compilation aborted for C:\sf61\proces\save.f (code 1)
Unable to open argument file, C:\Users\dave\AppData\Local\Temp\8132104arg3.

I also get the same errors except for the last argument file message for another routine using the same COMPL variable.

Interestingly enough, If I do another build only one file, but not both give the error.

I'm 100% certain there is only one definition of COMPL in a module.  But I'm concerned about the #10298 error and why it can't find the argument file.   Are these all related? These lines are all contiguous in the output window.

If I change every usage from COMPL to C0MPL (using a zero instead of O). the code all compiles and links fine.  And there is no reference to a COMPL in the .map file.  I do have variables COMP and COMPW defined in the same module. But I can't live with using a zero as the name gets used by our users, and I need it to be consistent.

Making a sample is nearly impossible and the code is proprietary.  I could break out pieces, to show, but that usually isn't too helpful. 

0 Kudos
21 Replies
andrew_4619
Honored Contributor II
1,655 Views
module bill
    implicit none
    integer :: ivar1, ivar2
end module bill
    
module fred
    implicit none
    integer :: ivar1, ivar_3
end module fred
    
Program test_program
     use fred
     use bill
     implicit none
     ! error #6405: The same named entity from different modules and/or program units cannot be referenced.   [IVAR1]
     ivar1 = 41
     print *, ivar1
end program test_program

So you you have something similar to the code above? In this case you need to decide which version  of Ivar you want to use in test_program and use the rename or only options on the USE statement(s)

0 Kudos
dajum
Novice
1,655 Views

As I said "I'm 100% certain there is only one definition of COMPL in a module." 

It would be really nice if the compiler told you where it found two definitions.  But as I said if I change the name there is no error message, and no definition of COMPL in the .map. 

What causes error #10298? Is this some sort of parallel issue?

And where and why does the compiler have a problem with it's own file? C:\Users\dave\AppData\Local\Temp\8132104arg3. is not created by me.

Dave

0 Kudos
andrew_4619
Honored Contributor II
1,655 Views

Interesting. What definitions do you get if you text search "COMPL" in your source? Is there a Parsing error for a malformed code line with the word "COMPLEX" or some other such?

0 Kudos
dajum
Novice
1,655 Views

Searching only finds the one instance.  That's why I changed the name so that some parsing error would still be showing COMPL in the .map. But that doesn't happen.  This truly seems like a compiler bug to me.  Especially since the  #10298 error and the file error.  But how to find what causes the error is my issue.  I can't live with the name change as a solution.
 

0 Kudos
andrew_4619
Honored Contributor II
1,655 Views

How can you get a valid map in the case where compilation fails?? I would have thought you would need to look in source?

0 Kudos
dajum
Novice
1,655 Views

There is no compilation error if I use a different name for the variable.  That's why it seems like a bug. 

0 Kudos
andrew_4619
Honored Contributor II
1,655 Views

So say the compiler (or your source)  has a bug which creates a name collision. You rename a variable and there is no collision so the "bug" is now not activated and the linker does not show the erronious symbol when it makes the map file..... You thus will not see the clue you are looking for in the map file.....

Can you break some source file into several files to try to isolate a problem that way?

0 Kudos
Lorri_M_Intel
Employee
1,655 Views

The problem with post processing is because one of the files being compiled in parallel (save.f)  gave an error, and the missing temporary file was expected to be generated by a successful compilation but wasn't.   I agree the message could be less obscure.

Your source file appears to be fixed-form, just judging from its file extension, so it could be something like Andrew suggested, and the "compl" is really "complex" but at the end of a line?  (kind of a stretch, but ...)

Do you have the /extend_source switch set?  If not, try setting that and see if it makes any difference.

                  --Lorri

 

 

 

0 Kudos
dajum
Novice
1,655 Views

Thanks Lorri, helps to know it isn't related.

Our source is fixed-form, but we already use the /extend_source switch, so that is unlikely to help.  There are not that many instances of the string COMPL that I can't look at them all to tell there is only one definition, or extended line issue. IMPLICIT_NONE is used to avoid problems with long lines and other typos.  And when I change each instance to a much longer string, the error goes away, and the code runs fine and behaves as expected.  If it was from my defining it twice I would think the error would not disappear, or at least there would be a COMPL reference in the .map file.  But we really want to use that name because it is exposed to the users, and changing it means changing documentation and similarities for naming. 

Since the module is in a dll, maybe something there is causing an issue with the compiler and the EXPORT of the symbol.  What is the compiler looking at to find the multiple references?

0 Kudos
Lorri_M_Intel
Employee
1,655 Views

When you compile a module, you get two output files.   One is the object file with executable code and actual storage space for any data declared in the module.  The other is the .mod file which only contains interfaces to the executable code, and declarations of the data.

When you compile a program that has USE THATMOD, it reads only the .mod file; whatever you have in your executable code (such as in your .dll) is not referenced at compiletime.

I can't tell which version of the compiler you're using; can you share that?

Here are some more weird questions about the code;

    Is COMPL in an only-list?  Ie, USE THATMOD, ONLY : COMPL

    Is COMPL defined in a module that is USEd by several other modules, some of which may have the PRIVATE attribute? 

    Can you share what that one definition of COMPL looks like?   Don't need to see all your code, just this one definition.

                         Thanks --

 

                         

0 Kudos
dajum
Novice
1,655 Views

Using 19.0.117, but also happens in 18 and 17

We never use an only list, or private attribute.

The module is used in 2 others.  Those two are never in same routine. 

Here is the module (not sure how the formatting will look here, but it is fine in the code):


      MODULE USER_LUMP_MOD
        REAL,ALLOCATABLE :: HL(:)
        REAL,ALLOCATABLE :: PL(:)
        REAL,ALLOCATABLE :: XL(:)
        REAL,ALLOCATABLE :: TL(:)
C        !DEC$ ATTRIBUTES DLLEXPORT :: TL
        REAL,ALLOCATABLE :: DL(:)
        REAL,ALLOCATABLE :: VOL(:)
        REAL,ALLOCATABLE :: VDOT(:)
        REAL,ALLOCATABLE :: QDOT(:)
        REAL,POINTER :: DF(:)  !export from DLL
        REAL,POINTER :: DG(:)  !export from DLV
        REAL,ALLOCATABLE :: AL(:)
        REAL,ALLOCATABLE :: COMP(:)
        REAL,ALLOCATABLE :: COMPL(:)
        REAL,ALLOCATABLE :: COMPW(:)
        REAL,ALLOCATABLE :: CX(:)
        REAL,ALLOCATABLE :: CY(:)
        REAL,ALLOCATABLE :: CZ(:)
        REAL,ALLOCATABLE :: QCHEM(:)
        REAL,ALLOCATABLE :: QTM(:)
        REAL,ALLOCATABLE :: QHTRL(:)
        REAL,ALLOCATABLE :: QL(:)
        REAL,ALLOCATABLE :: ASL(:)
        REAL,ALLOCATABLE :: CASL(:)
        REAL,ALLOCATABLE :: UVI(:)
        REAL,ALLOCATABLE :: ULI(:)
        REAL,ALLOCATABLE :: CUVI(:)
        REAL,ALLOCATABLE :: CULI(:)
        REAL,ALLOCATABLE :: AST(:)
        REAL,ALLOCATABLE :: UVT(:)
        REAL,ALLOCATABLE :: ULT(:)
        REAL,ALLOCATABLE :: CUVT(:)
        REAL,ALLOCATABLE :: CULT(:)
        REAL,ALLOCATABLE :: CAST(:)
        REAL,ALLOCATABLE :: VDRP(:)
        REAL,ALLOCATABLE :: VBUB(:)
        REAL,ALLOCATABLE :: PH(:)
        REAL,ALLOCATABLE :: ZJ(:)
        INTEGER,ALLOCATABLE :: IDGC(:)
        !DEC$ ATTRIBUTES DLLEXPORT :: HL,PL,XL,TL,DL,VOL,VDOT,QDOT,DF,DG,AL,COMP,COMPL,COMPW,CX,CY,CZ,QCHEM,QTM,QHTRL,QL
        !DEC$ ATTRIBUTES DLLEXPORT :: ASL,CASL,UVI,ULI,CUVI,CULI,AST,UVT,ULT,CUVT,CULT,CAST,VDRP,VBUB,PH,ZJ,IDGC
      END MODULE

 

0 Kudos
Lorri_M_Intel
Employee
1,655 Views

Do you USE IFPORT in your application?  More specifically, in save.f?

I've found a generic interface in the set of portability routines that has the string "COMPL"

 

 

0 Kudos
dajum
Novice
1,655 Views

Yes those routines with the error use IFPORT.  Is there an easy way to exclude that name from being found in IFPORT?

0 Kudos
andrew_4619
Honored Contributor II
1,655 Views
Rename it on the use of port line is the quickest way.
0 Kudos
andrew_4619
Honored Contributor II
1,655 Views
I always use the only qualifier using things like iport as it a makes clear what is being used and stops namespace pollution.
0 Kudos
dajum
Novice
1,655 Views

So I added ONLY :DELDIRQQ to the USE DFPORT statement. 

That got rid of the 6405 error.  But now I get:


C:\sf61\proces\save.f(583): error #6404: This name does not have a type, and must have an explicit type.   [COMPL]
C:\sf61\proces\restar_old.f(560): error #6404: This name does not have a type, and must have an explicit type.   [COMPL]
C:\sf61\proces\resave_old.f(337): error #6404: This name does not have a type, and must have an explicit type.   [COMPL]

This name is clearly typed and defined in my module, the same as every other variable in the module. Every variable in the module listed above is used in these subroutines, yet only COMPL is getting this error.  Doesn't seem to be a coincidence.  I tried creating a simple sample doing the same thing.  It doesn't fail, so there must be something more complex happening in my actual code. Any thoughts on this are appreciated as I'm still trying to get this working.

0 Kudos
dajum
Novice
1,655 Views

nevermind.  Seems a complete rebuild was necessary to get the errors to go away. 

Thanks for you help!

Dave

0 Kudos
dajum
Novice
1,655 Views

And then the 6404 errors come back randomly.  Something doesn't check names correctly.

 

0 Kudos
Lorri_M_Intel
Employee
1,655 Views

Do you mean these have come back?

C:\sf61\proces\save.f(583): error #6405: The same named entity from different modules and/or program units cannot be referenced.   [COMPL]

Is it still our buddy COMPL, or has someone else joined the party?

 

0 Kudos
dajum
Novice
1,334 Views

No just the 6404 errors from #17.  We decided we are just going to change the name.  The 6404 just seem really random.

0 Kudos
Reply