ASSOCIATE statement causes unrelated spurious compile errors

[qolin]

Upgraded from 10.1 to 11.1 yesterday, and *eagerly* started replacing local pointers with ASSOCIATE statements. First file went fine, but second one (attached) caused problems. I tried to narrow it down by eliminating code, at which point I hit an internal Compiler Error. That was version 11.1.048.

A quick look here led me to the release notes for 11.1.054, which gave hope the problem might be fixed, soI downloaded and installed it. This fixed the Internal Compiler Error, but the original problem remained.This is what the compiler has to say:

Compiling with Intel Visual Fortran 11.1.054 [IA-32]...

do_pipe_sector.f90

D:\\ip4\\Main\\pipesim\\engines\\components\\psim\\do_pipe_sector.f90(131): error #6780: A dummy argument with the INTENT(IN) attribute shall not appear in a variable definition context [SECTOR]

D:\\ip4\\Main\\pipesim\\engines\\components\\psim\\do_pipe_sector.f90(132): error #6780: A dummy argument with the INTENT(IN) attribute shall not appear in a variable definition context [SECTOR]

D:\\ip4\\Main\\pipesim\\engines\\components\\psim\\do_pipe_sector.f90(133): error #6780: A dummy argument with the INTENT(IN) attribute shall not appear in a variable definition context [SECTOR]

<...etc >

compilation aborted for D:\\ip4\\Main\\pipesim\\engines\\components\\psim\\do_pipe_sector.f90 (code 1)

Build log written to "file://D:\\ip4\\Main\\pipesim\\engines\\components\\psim\\Debug\\BuildLog.htm"

psim - 17 error(s), 0 warning(s)

All this happens when I swap ONE local pointer for the same symbol in an associate statement. In the attached file, the associate is on line 107, and it replaces the pointer declaration and assignment on lines 74 and 94. The reported errors concern the use of the structure argument SECTOR in lines 131 onwards. Notice that the text of the error message says that SECTOR is defined with intent(IN), which is not true, it has intent(INOUT).

SO ... the questions are:

(1) is there in fact anything wrong with the use of SECTOR at the lines in question?

(2) is there some limitation on the use of ASSOCIATE that I have overlooked?

(3) Has anyone hit this sort of problem before, and if so, can they suggest a work-around?

I would like to report this to premier support, but there is A LOT of code involved; not just in the attached file, but also in the cascade of USEd modules, so I'm trying the forum first. (And anyway it might be my foul-up)

[Steven_L_Intel1]

Offhand, I don't spot a problem with your code. I tried to construct a minimal test case based on what you posted, but it worked fine for me. Perhaps you can cut down the problem source to the minimum needed to show the problem?

[qolin]

Thanks for looking Steve.

Alas I tried cutting it down when I was investigating the internal compiler error with 11.1.048. I got it down to 10 or so lines with 2USE statements, but those modulesare extensive and reference tons of others. I can't justify the time required to take it further just now. Maybe in a few weeks when things calm down around here.

Now, if I can just figure out what a CLASS statement does (all this OO guff must be good for something!)

Cheers

Qolin

[Steven_L_Intel1]

CLASS specifies that the object may have more than one possible type and that the type may change during execution of the program.

If you don't want to do the work of isolation, give us the whole thing through Premier Support and we'll do it - we're experienced at that.

[qolin]

Thanks for looking Steve.

Alas I tried cutting it down when I was investigating the internal compiler error with 11.1.048. I got it down to 10 or so lines with 2USE statements, but those modulesare extensive and reference tons of others. I can't justify the time required to take it further just now. Maybe in a few weeks when things calm down around here.

Now, if I can just figure out what a CLASS statement does (all this OO guff must be good for something!)

Cheers

Qolin

[Steven_L_Intel1]

You can try 11.1.054, or wait for Update 5 in a couple of weeks.