Automatic interface blocks in 11.1.060?

[jarvusluntatintel]

I just updated from 11.0.3454 to 11.1.060. (I was having issues viewing variables with the debugger and wanted to see if the latest version made the problem go away).

The compiler is now "locking up" on a subroutine that previously compiled. When I go to /degug directory, I am now getting foo__genmod.f90 files. Is __genmod.f90 an interface block? Because of the legacy way that my code is set up (with derived types being defined by include files; the derived types are sometimes, but not always, created inside of modules) interface blocks cause problems. Under options I have generate interface block set to no. I am confused as to what is going on now. (It's also a bit frustrating that Fortran help is now giving me general .net and C results.)

For the subroutine in question, it is generating foo__genmod.f90 (9k), it has created a foo.obj, but the size is 0k.

[jarvusluntatintel]

For the remainingroutines, I am getting hundreds of messages:

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

Which is why I had turn to interface blocks off.

[Steven_L_Intel1]

The __genmod.f90 (and .mod) files are created by the generated interface checking feature. This feature is for error diagnosis only, and if your program is written so that argument mismatches are deliberate you can certainly turn this off. Note that you want to disable "Check routine interfaces" as well as "Generate interface blocks" to completely disable this.

If you can provide the source of the subroutine that is causing the compilation problem, plus the __genmod files for any routines it references, that would help us analyze the problem and fix any bugs it may show.

[jarvusluntatintel]

Steve

Thanks for the quick response. Somehow the check routine Interface and generate interface block got turned on when I did the update. I'm aware of this feature (since it has effected me in the past). Things were working, I did the update, and, these flags were switched (apparently on their own).

I turned off generate interface. I missed that I needed to turn off Check routine interface also.Getting both turned off has fixed the problem (or at least things appear to be better).

The routine that was "locking up" (when generate interface is on)I have stripped down to a small sample. This is not a problem for me, but I assume you would want to look at why it is not returning with some sort of normal error/warning. I will try to attach it to this post or the next.

[jarvusluntatintel]

Sample problem is attached.

[jarvusluntatintel]

I'm happy to report that the strange debug viewer behavior I was getting in 11.0 is now fixed. :-)

[Steven_L_Intel1]

Thanks, I can reproduce this.

[Steven_L_Intel1]

The compiler hang (it goes CPU bound) is escalated as issue DPD200153399. Only /gen_interface is needed to see this.

[Steven_L_Intel1]

This problem has been in the compiler for years, but requires a very specific set of circumstances to trigger, including the length of names of the derved type components. We have fixed it but, at present, won't be includng the fix in an 11.1 update as there is a simple workaround. If you feel differently, please let me know.

[jarvusluntatintel]

I'm not concerned about this fix, since I am not using thegen/check interface feature.

I'm a little concerned about theproject properties/flags, however. When I load old/archived solutions/projects, the check interface flag is shown as Yes. My program won't compile and link with interface checking (so I presume my older, successful solutions did not have this checked), so I assume this flag is getting "flipped"when the newer version of the Intel compiler loads my older projects. Which this flag doesn't bother me, now that I know to go turn it off. However, it makes me wonder if any other settings are getting changed.
Or did the older compiler only do the check if the generate interface flag was also yes, which would make the behavior more understandable.

[Steven_L_Intel1]

Prior to 11.1, you needed both /warn:interface and /check:interface - after that just /warn:interface was sufficient.