GCC Bugzilla – Bug 38979
OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
Last modified: 2009-12-23 13:15:39 UTC
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
dimension x1(1), vx1(1)
c Gather xJ,yJ,zJ(J=1,8)
c$omp thread private (/aux33loc/)
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. ***
Comment to the patch:
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:-)
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, does a single threadprivate var make all vars equivalenced somehow to
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 , Intel does not write anything about it  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 .)
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.
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 , Intel does not write
> anything about it  and for sun I couldn't find anything.
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.
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.