gomp - equivalence for threadprivate data

Tim Prince TimothyPrince@sbcglobal.net
Mon Jan 26 13:38:00 GMT 2009


Matevz Tadel wrote:
> 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
I have done very little work with geant, so I can't comment usefully, but
I would be surprised if it doesn't have provision to build with those
compilers.  We do use ifort and pgf90 to build other applications which
violate OpenMP standard in this respect.  I wasn't aware of a stated
limitation in pgf90 documentation, which would acknowledge that
EQUIVALENCE may present variations which can't be supported.



More information about the Fortran mailing list