Error 5544 meaning?

[dajum]

I get

> astap.for(8402): error #5544: Declaration of globally visible name conflicts with a common block declaration

>

> SUBROUTINE VA00030

>

> ---------------------------^

But I don't see anything at all wrong with the subroutine name, or any common blocks within the routine. Any help interpreting what this apparently undocumented error code means?

Thanks

Dave

[Steven_L_Intel1]

I would have to see more of the program. There is a similar error 5412 with the same text. Both of these, I think, are triggered when you have done something that changes the external name of an object to be the same as a common block (or changed the common block name). !DEC$ ATTRIBUTES ALIAS can be used for this.

[dajum]

The code is on a classified system that makes it difficult to show anything involved with the code. There are no !DEC$ in the main or the subroutine giving the error. But there is an interface module that is used. But it doesn't give error if that one subroutine is removed. Do you have a concrete example for the error?

[Steven_L_Intel1]

I am looking for an example. Do you use BIND(C)?

[Steven_L_Intel1]

Which exact version of the compiler are you using? Please show the output of "ifort" from a command prompt.

[dajum]

No. This problem is occuring in 11.1.054. I'm trying to get the user to update to a newer version of 11.1. I'm hoping it is a bug in the compiler, but we haven't been able to isolate the cause other than to completely remove the one subroutine that the compiler flags.

[Steven_L_Intel1]

The following program triggers that error:

common /foo/ a, b, c
real a, b, c(100)
!dec$ attributes alias : "_BAR" :: foo
call bar(12)
end

Can you move that subroutine to a separate source file and will it compile then? This is one of those machine-generated sources, right?

[dajum]

Yes it is a machine-generated source, with hand generated code inside the routine that is failing. I'll see if we can compile it separately and what that tells us.

[Steven_L_Intel1]

Please also search the source for all occurrences of the subroutine name string and see what you find.

[dajum]

We did that first. Also trying to seach across line breaks for anything similar. There was only the definition of the routine, and one call of the routine. So we don't think it is the routine name.