gomp - equivalence for threadprivate data

Matevz Tadel matevz.tadel@cern.ch
Mon Jan 26 13:23:00 GMT 2009


n8tm@aol.com wrote:
> 
> 
> 
> -----Original Message-----
> From: Matevz Tadel <matevz.tadel@cern.ch>
> To: fortran@gcc.gnu.org
> Cc: Federico Carminati <Federico.Carminati@cern.ch>
> Sent: Thu, 22 Jan 2009 11:32 am
> Subject: gomp - equivalence for threadprivate data
> 
> Hello, 
>  
> We are trying to parallelize a program that contains a legacy f77 
> project (GEANT3, ~200k loc). The code uses equivalence statements 
> between array elements and common members extensively, e.g.: 
>  
>   COMMON/GCPARM/IPARAM,PCUTGA,PCUTEL,PCUTNE,PCUTHA,PCUTMU 
>   + ,NSPARA,MPSTAK,NPGENE 
>   REAL PACUTS(5) 
>   EQUIVALENCE (PACUTS(1),PCUTGA) 
>  
> We are aware that OpenMP specification explicitly states that common 
> members and variables with the threadprivate specifier must not be 
> present in equivalence statements. However, as we want to use the 
> equivalence among variables that are all threadprivate within the same 
> compilation unit, the reason why this limitation could not be lifted is 
> not clear to us. 
>  
> Thus, we would hope to get the following pragma to compile successfully 
> (for the above example) 
>  
> !$omp threadprivate(/GCPARM/, PACUTS) 
>  
> as the equivalnce simply needs to do what it would have done in a 
> non-parallel program (with the exception of mapping into the 
> thread-local data). 
>  
> Is there an error in our reasoning? 
>  
> We are willing to do most of the work needed for implementation of such 
> an extension but would defintely need some help and guidance. 
>  
> In any case, even if there is no hope to get such an extension into the 
> official version, we would still like to bypass this issue as we are 
> trying to estimate if paralellization of our code makes any sense at all 
> due to possible issues with cache trashing and I/O bottlenecks. 
>  
> Thanks in advance! 
>  
> Best regards, 
> Matevz 
>  
> Currently we are using: gcc --version 
> gcc (GCC) 4.3.3 20081110 (prerelease)
> ___________________________________________-
> For what it's worth, this is the one major obstacle I have run into in 
> the use of gfortran for compiling legacy applications.  All commercial 
> compilers in my experience support the extension to the OpenMP standard, 
> in part because of the importance of this application.  
> I suppose the limits under which this is practical aren't well defined.  
> For example, I wouldn't expect it to work for cases where EQUIVALENCE 
> enlarges the data region.
> Tim Prince

Thanks for your reply.

I tried with ifort but it reports the same error (the documentation doesn't 
mention anything about this). PGI fortran documentation explicitly states this 
is not allowed.

Which compiler would you suggest to try?

Best,
Matevz



More information about the Fortran mailing list