Trouble with Logical .AND. Operator

[jackosullivan1]

Compiling a purely Fortran program -- self-contained exe --with the following options generated through the MS VisualStudio 2003.NET (a la Visual C++.NET):

/nologo /Zi /Od /include:"Debug/" /fpscomp:filesfromcmd /fpscomp:ioformat
/fpscomp:logicals /fpscomp:general /error_limit:10 /warn:errors /warn:unused
/warn:interfaces /real_size:64 /Qsave /align:rec8byte /align:dcommons
/assume:dummy_aliases /Qzero /fpe:0 /iface:cvf /module:"Debug/" /object:"Debug/"
/traceback /check:bounds /check:format /libs:qwin /c

I'm getting an erroneous ".TRUE." with the following code which is in a .f90 source file. I am linking it witha large number of .for files, but all the action involved in this erroris local to the .f90source. (Line numbers are for reference only and not included in the code):

1 Logical a,b

2 x=1.
3 y=2.
4 a=.TRUE.
5 v=0.
6 if(v=0.)b=.FALSE.

7 if(a .AND. b)then
8 p=x/v
9 else
10 p=x/y
11 endif

Line 8 gets executed whenever a is .TRUE. (according to the cursor-hover help in MSVS2003.net), regardless of the value of b... not a nice thing when I have a zero in v.

Any ideas on what I might be doing wrong would be greatly appreciated.

Thanks and God bless!
Jack O'Sullivan

[Steven_L_Intel1]

No, we're not going to change the default binary interpretation of LOGICALs. I would recommend that you turn off /fpscomp:logicals and see what happens.

[jimdempseyatthecove]

Steve,

I have not studied the Fortran 2003 standard. I am consulting the IVF documentation click on "scope" do not click on "of unambiguous..." and combined with info on namedCOMMON blocks. From my understanding of the documentation:

module 1 can create a named common block which contains a variable named X

module 2 can create a differently named common block which contains different variable named X

module 1 and module 2 can be compiled seperately thus creating two copies of X within the scope of the respectivelynamed common.

Subprogram Y using module 1 or module 2 can unambiguously view the host scope named COMMONX.
Subprogram Y using module 1and module 2 can ambiguously view the host scope named COMMON X.
(unambiguously with scoping operator ::)

Subprogram Y can(arguably) create local scope class I variable named X because X as previously declared in USE (either or both) is in a Host scoping unit and thus not declared in the local(sub-ordinant) scoping.

The "(arguably)" is an issue that should have been addressed by the F2003 standard which I have not studied. I defer this to your interpretation of the standard.

Note, if the two modules each contain a module scoped variable named X (i.e. not in COMMON) then a subprogram could not use both both modules... Or at least not use both and then reference X without scoping the variable.

Jim Dempsey

[Steven_L_Intel1]

Jim, that is not correct.

First, there is no "scoping operator" in the Fortran language. The use of :: you mention is a convention we offer in the debugger, that is all.

This is what the standard says:

18 An accessible entity in the referenced module has one or more local identifiers. These identifiers are
19 (1) The identifier of the entity in the referenced module if that identifier appears as an only20
use-name or as the defined-operator of a generic-spec in any only for that module,
21 (2) Each of the local-names or local-defined-operators that the entity is given in any rename for
22 that module, and
23 (3) The identifier of the entity in the referenced module if that identifier does not appear as a
24 use-name or use-defined-operator in any rename for that module.

25 Two or more accessible entities, other than generic interfaces or defined operators, may have the same
26 identifier only if the identifier is not used to refer to an entity in the scoping unit. Generic interfaces and
27 defined operators are handled as described in section 16.2.3. Except for these cases, the local identifier
28 of any entity given accessibility by a USE statement shall differ from the local identifiers of all other
29 entities accessible to the scoping unit through USE statements and otherwise.

So in your scenario, if subprogram Y uses both modules 1 and 2, subprogram Y must not reference the name X.

More to Jack's problem, the standard also says:

30 The local identifier of an entity made accessible by a USE statement shall not appear in any other
31 nonexecutable statement that would cause any attribute (5.1.2) of the entity to be specified in the
32 scoping unit that contains the USE statement, except that it may appear in a PUBLIC or PRIVATE
33 statement in the scoping unit of a module and it may be given the ASYNCHRONOUS or VOLATILE
34 attribute.

This means that the local identifier X that comes from the module must not be named in a declaration in the subprogram, with the exceptions shown. There's no exception for COMMON variables. The standard also has this note:

NOTE 11.10
The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name from appearing as a
common-block-object in a COMMON statement, an equivalence-object in an EQUIVALENCE statement,
or a namelist-group-name in a NAMELIST statement, respectively. There is no prohibition
against the local-name appearing as a common-block-name or a namelist-group-object.

[jimdempseyatthecove]

Thanks Steve for locating the specification and clarifying the issue.

In what you quoted and stated

Module 1 could have X
Module 2 could have X (different X)
code could use both module 1 and 2 but not reference nor declare it's ownX

Too bad about not having localized scoping such as C/C++{ and } whereby one could declare something ubiquitous such as "TEMP" without running afoul of something in some module that may be supplied by a 3rd party and eventualy clash with a long standing variable name used in someone's application.

BTW withmy programming style I tend to use

module mod_foo
type type_foo
real ::X
integer :: ...
end type type_foo

type(type_foo) :: foo
end module mod_foo

...

use mod_foo
...
foo.X = 1234.

When I convert older files I also create a

! mod_foo.inc
#define X foo.X

Then on compilation units that have "use mod_foo" I also have "#include 'mod_foo.inc'" (and be careful to only #include it once per compilation unit that requires it).

Jim Dempsey

[Steven_L_Intel1]

Yes, this does catch a lot of programmers unawares, and it took me quite a while before it sunk in that, in this regard, Fortran was not like Ada! However, all is not lost - you can use renaming and ONLY to control the imported names so that they don't conflict. In fact, the Fortran style is in some ways better as it catches problems (such as Jack's, if the compiler didn't have a bug here) that would otherwise go undetected.

You can still have a problem with host association, though. The following is legal:

module mymod
integer i
contains
subroutine mysub
integer i
...

In this case, the module variable I is hidden inside routine mysub, which could be a problem if you were expecting to use the shared version. More often I see issues with code such as this:

module mymod
contains
subroutine sub1
external sub2
call sub2
end subroutine sub1
subroutine sub2
...

Here, the "external" declaration, which may be a holdover from an earlier F77-style implementation, hides the module procedure sub2 and refers to some (perhaps undefined) external procedure sub2.