[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #13 from Dominique d'Humieres --- > > Any progress after six years? > > PING! No feedback, closing as WONTFIX.
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979 Dominique d'Humieres changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Dominique d'Humieres --- > Any progress after six years? PING!
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #11 from Dominique d'Humieres --- Any progress after six years?
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #10 from arjen dot verweij at tass-safe dot com 2009-12-01 15:10 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #9 from matevz dot tadel at cern dot ch 2009-06-08 10:42 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #8 from arjen dot verweij at tass-safe dot com 2009-05-19 10:59 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #7 from burnus at gcc dot gnu dot org 2009-05-18 16:52 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #5 from arjen dot verweij at tass-safe dot com 2009-03-04 18:23 --- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #4 from pault at gcc dot gnu dot org 2009-02-19 06:04 --- 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 -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-19 06:04:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #3 from burnus at gcc dot gnu dot org 2009-02-10 17:05 --- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-26 18:42 --- 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 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|OpenMP extension: |OpenMP extension: ||THREADPRIVATE for ||EQUIVALENCEd symbols http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-01-26 18:50 --- *** Bug 38947 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||matevz dot tadel at cern dot ||ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
