Community
Participate
Working Groups
From e-mail ("Re: Workspace & updated file" 4/7/09): When I start my program transformation I see many warnings that a particular include file could not be found, though I made sure that it is present in the project's folder. But this did not result in any problems so far. I noticed another problematic issue. In the attached files I reproduced the problematic part. Subroutine "morton_neighbors" receives an argument "ndim" and uses module "physicaldata", which uses another module - "paramesh_dimensions". Module "paramesh_dimensions" declares a constant, which has the same name as the argument of the subroutine - "ndim". Constant "ndim" from the module "paramesh_dimensions" does not conflict with the argument "ndim" of the subroutine "morton_neighbors", because of the "private" declaration in the module "physicaldata", which makes all entities (variables, subprograms) of this module (including those from the used modules) to have private visibility by default. So, this code can be successfully compiled (but if we remove "private" declaration from the module "physicaldata", the compiler will complain about an ambiguous reference to "ndim" in the subroutine "morton_neighbors"). The problem is the following: when my code tries to get definitions for a reference to "ndim" inside the subroutine "morton_neighbors", it gets both definitions - from the subroutine and from the module "paramesh_dimensions", and this results in an exception. It seems that only one definition should be associated with the reference of "ndim" inside the subroutine - the definition from the subroutine. Att (FLASH): paramesh_dimensions.f90 physicaldata.f90 subroutine.f90
This was a lot trickier than I thought -- the VPG was not prepared to handle the idea that one symbol could have different visibilities depending on which module it is relative to. Anyway, I finally got it fixed and put a regression test in CVS. Jeff
Forgot to close this out
