iercd from IMSL

[lrpartin]

I am curious about an issue. I am compiling a project in 6.5A that worked in 6.1. In 6.1, I have the code:

integer iercd
external iercd

because the iercd function was left out of numerical_libraries.f90. I see that it was added in 6.5. The compile step now complains about a name conflict with iercd made available by the USE command. That makes sense. My question is that the compiler does not find a problem in my second f90 file where I have iercd in several routines. The routines are part of a module and I have the use numerical_libraries command as the first line of code in the module. I seems as though the compiler should give the same error for the integer iercd & external iercd statements for these functions contained in the module. The compiler is fine with or without the statements.

Thanks,
Lee

[Steven_L_Intel1]

The contained routines have a different scope than their enclosing module, so the EXTERNAL declaration of IERCD hides that imported from NUMERICAL_LIBRARIES. If you had USE NUMERICAL_LIBRARIES in the routines themselves, you'd get the error.

Steve

[lrpartin]

Steve,

Does it work properly with the USE NUMERICAL_LIBRARIES statement within the module declaration and not within each of the routines contained within the module? It seems to work fine.

The scope issue is confusing to me. The routines have their scope of variables that are unique to the routine but they also have access to the variables in the module that they are a part of.

I did some checking with the compiler to see the impact of this scope issue. The routine can override the module variable with its own variable. I am surprised that the compiler does not give a warning. The compiler does give a warning for a separate routine that USEs the module but it doesn't give the warning within the module?????

Thanks,
Lee

[Steven_L_Intel1]

This is the way Fortran 90 works. The module is one scope, the contained routine is a nested scope. You can't declare and reference two objects of the same name in a particular scope, but if one of the declarations is inherited from an outer scope, it is "hidden" by the inner declaration. A USE statement in effect declares all the items in the scope where the USE appears.

If you USE NUMERICAL_LIBRARIES at the module level, and then declare IERCD in the contained routine, that declaration hides the one inherited from the module's USE.

Steve

[lrpartin]

Thanks, Steve. I see how it works but it seems logical that the compiler would warn about the hiding of the inherited declarations for the routines contained in the module. Part of the benefit of modules is how the compiler provides the extra checks for correct coding but now I see that the compiler doesn't check internal to the module.

Lee

[Steven_L_Intel1]

The compiler shouldn't "warn" because this is considered a normal part of Fortran programming.

I don't know what you mean by "doesn't check internal to the module".

Steve

[Intel_C_Intel]

I think the request is for a compile time warning that the local variable x in contained procedure foo hides the variable x in the host's scope. If so, it's not an unreasonable suggestion.

[Steven_L_Intel1]

I understood what was asked for - I just commented that this is a normal Fortran 90 usage and it's not clear to me it justifies a "warning", because there are many legitimate reasons one might do this. We'll consider it as an optional informational, though.

Steve

[Intel_C_Intel]

Agreed that it is a standard conforming coding practice and may have legitimate purposes. So maybe 'warning' is too strong; 'informational' works for me. FWIW though, most times I've discussed this issue with others (admittedly, in C++ where I think we called it a 'hole in scope') it was with a 'beware' caution or even as a possible culprit in a bug.

But, as far as 'warnings' or 'informationals' go, and as long as we're talking about suggestions, let me mention again that I'd first really like to see the capability to turn off specific warnings and informational messages. :-)

Thanks,
John

[lrpartin]

Steve and John,

Thanks for the information on how the system works. As I understand it now,
(1) When a routine has 'USE X', the public part of X comes into the scope of that routine. It is then a compile error to try to override something that some from X.
(2) A routine contained within module X has a nested scope of the module and the compiler has no concern about it overriding module private or public declarations.

For (2), you state that it is common and right for the programmer to do this. It seems that a programmer would have just as much reason to do it for (1) as for (2).

What is the informational message mentioned above? I checked under Project .. Settings .. Fortran .. Comilation Diagnostics and found three options: Ignore Warnings, Normal Warnings, & Warnings Treated as Errors.

Thanks,
Lee

[Steven_L_Intel1]

There is no informational message for this at present.

Steve

[lrpartin]

Steve,
Do `informational messages` exist in CVF or are you proposing this as a future feature of the software?
Lee

[Intel_C_Intel]

Hi Lee,

When I said (2) was 'a standard conforming coding practice', I meant that with respect to the f95 standard, (2) is acceptable - it is not 'illegal'. There also actually may be legitimate reasons for doing (2). However, it is not my opinion that the practice of doing (2) is at all common or correct. In fact, imo, although there may be legitimate reasons for doing (2), it is not common and it's usually a programming mistake (again, my opinion).

In the case of (1), there are alternative methods to deal with some of the issues in which you might have considered it. For example, the use statement can have an only specifier to restrict what is imported from a module, and a rename list can be utilized in the only statement to avoid name clashes. There's just no valid reason to do (1); that's why it is a compiler error.

The informational (or warning) message was mentioned in the context of a possible future compiler feature. (2) is not diagnosed today.

hth,
John

[lrpartin]

John,

Thanks, I had not reviewed the USE command to see how easy it is to change the name of a conflicting variable/routine for case (1).

I now see that the previous usage of the term 'Informational Message' meant that it would be a compiler warning if implemented in the future.

Lee