See also: http://gcc.gnu.org/ml/fortran/2009-01/msg00308.html Seemingly, a lot of the OpenMP-supporting compilers support THREADPRIVATE for EQUIVALENCEd symbols; at least Intel's ifort, SUN's sunf95, Open64's openf95, Pathscale's pathf95 and Portland's pgf95 compile the program listed at gfortran rejects it with: Error: EQUIVALENCE attribute conflicts with THREADPRIVATE attribute !------------------------------------------------------------- c subroutine strainx(x,volo,v,lft,llt,volf,vlim) c c dimension x1(1), vx1(1) integer nlq parameter (nlq=544) integer nnlq,lq9,lq0,lq1 common/newnlq/nnlq,lq9,lq0,lq1 common/aux33loc/ix1(nlq),ix2(nlq),ix3(nlq),ix4(nlq),ix5(nlq), 1 ix6(nlq),ix7(nlq),ix8(nlq),mxt(nlq) c dimension x(3,*),v(3,*),volo(nlq),volf(*),vlim(*) dimension ixx(nlq,8),posn(nlq,8,3),posv(nlq,8,3) equivalence (ixx(1,1),ix1(1)),(posn(1,1,1),x1(1)) & ,(posv(1,1,1),vx1(1)) c c Gather xJ,yJ,zJ(J=1,8) c$omp thread private (/aux33loc/) do node=1,8 do i=lft,llt posn(i,node,1)=x(1,ixx(i,node)) posn(i,node,2)=x(2,ixx(i,node)) posn(i,node,3)=x(3,ixx(i,node)) enddo enddo c return end
Note: The standard does not allow this, see http://www.openmp.org/mp-documents/spec30.pdf, page 94: Section "2.9.2 threadprivate Directive" has under "Restrictions": "A variable can only appear in a threadprivate directive in the scope in which it is declared. It must not be an element of a common block or appear in an EQUIVALENCE statement." I don't see any fundamental problem with allowing it thus simply removing the check should work - but I have not tested it. I think one should not silently accept it; as there is no -fopenmp-std=legacy option, I think the easiest would be to generate a warning such as: Warning: OpenMP extension: THREADPRIVATE for EQUIVALENCEd variable
*** Bug 38947 has been marked as a duplicate of this bug. ***
A patch: http://gcc.gnu.org/ml/fortran/2009-01/msg00325.html Comment to the patch: http://gcc.gnu.org/ml/fortran/2009-02/msg00050.html
Tobias, It seems to me that your proposal to permit this with a warning is good. However, will it work on all architectures? I am confirming it with some trepidation since it is not a bug:-) Paul
Do these patches have any chance of making it into an official release? We are using gfortran to compile code that is accepted by a string of compilers, but not this one :) Perhaps it is a good idea to treat this as an error that also provides a workaround; similar to code that uses cray pointers you are required to provide -fcray-pointer to compile it and errors if you don't?
I think it should only be a gnu extension, i.e. compile with -std=gnu or -std=legacy, but fail with any of the -std=f*. I know it's not exactly Fortran-standard-related, but I don't think we want to allow it when the user asks for standards conformance.
Issue brought up by Jakub: do you require all equivalenced vars to be either threadprivate or non-threadprivate? or, does a single threadprivate var make all vars equivalenced somehow to it threadprivate? Issues brought up by those creating the patch: There is a problem for saved variables - there the equivalence does not work. One has two options: 1. Remove the equivalence statements and replace the aliases in the code. 2. Create a "local" common block with the saved variables. If the variables were initialized via data statements one has to take care of that at the first entry into the routine. Thus, Jakob wants to have a full specification first. I looked at other compilers and while IBM does not seem to allow it [1], Intel does not write anything about it [2] and for sun I couldn't find anything. (Still, several compilers support it: Intel's ifort, SUN's sunf95, Open64's openf95, Pathscale's pathf95 and Portland's pgf95; maybe even IBM although it is not mentioned at [1].) [1] http://publib.boulder.ibm.com/infocenter/lnxpcomp/v101v121/topic/com.ibm.xlf121.linux.doc/proguide/threadprivate.html [2] http://www.intel.com/software/products/compilers/docs/flin/main_for/lref_for/source_files/rfthred.htm
We use xlf 10.1.0.0 5724-M1300 on AIX and there is no problem there. The V10 manual[x] also prohibits it, but I don't see the V12 manual stating they broke backwards compatability, so I will assume that it works just fine with V12. [x] http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlf101a.doc/xlfopg/smpdirdetails.htm For your reference, we compile code in violation of the OpenMP standard just fine on: hpparisc: HP-UX f90 20030609 (172812) B3907DB/B3909DB B.11.01.67 PHSS_28996 HP F90 v2.6.7 hpia64: HP-UX f90 B.11.23.22 PHSS_32711/PHSS_32712 ibm on g5: xlf 10.1.0.0 5724-M1300 linux24 ia32: Intel Fortran Version 8.1 Build 20050702Z linux24 ia64: Intel Fortran Itanium compiler Version 9.0 Build 20050912 linux24_x86_64: PGI compiler pgf90 6.1-2 linux26-x86_64: PGI compiler pgf90 6.1-2 linux24-em64t: Intel Fortran Compiler ifort 9.1 sgi64r10k: Fortran 77, 7.4.3m We also compile on win32 and win64 but I don't have the compiler specifics atm. I have tried to figure out how it came to be that so many compilers are not compliant, but I can't find a good source. (In reply to comment #7) I looked at other > compilers and while IBM does not seem to allow it [1], Intel does not write > anything about it [2] and for sun I couldn't find anything. > [1] > http://publib.boulder.ibm.com/infocenter/lnxpcomp/v101v121/topic/com.ibm.xlf121.linux.doc/proguide/threadprivate.html
Replying to comment 7: > do you require all equivalenced vars to be either threadprivate > or non-threadprivate? > or, does a single threadprivate var make all vars equivalenced somehow to > it threadprivate? It would be cleaner and less ambiguous if all equivalenced commons/variables are required to be declared threadprivate. > There is a problem for saved variables - there the equivalence does not work. > One has two options: > 1. Remove the equivalence statements and replace the aliases in the code. > 2. Create a "local" common block with the saved variables. If the variables > were initialized via data statements one has to take care of that at the > first entry into the routine. This was more a technical comment as SAVE statement was not discussed before and in our legacy code we also had 3 such occurrences (equivalence among saved array elements and local variables). The patch does not address the SAVEd variables, so an error is still generated. Potentially the scope of the patch could be extended to also cover the SAVE statement.
Hi, Is there any discussion going on still about this? We are getting rid of all of our UNIX workstations and moving to Linux. Incorporating the patch as an optional switch or similar would be nice. Thanks, Arjen
Any progress after six years?
> Any progress after six years? PING!
> > Any progress after six years? > > PING! No feedback, closing as WONTFIX.