User account creation filtered due to spam.

Bug 38979

Summary: OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols
Product: gcc Reporter: Tobias Burnus <burnus>
Component: fortranAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED WONTFIX    
Severity: enhancement CC: arjen.verweij, gcc-bugs, jakub, matevz.tadel
Priority: P3 Keywords: openmp
Version: 4.4.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2009-02-19 06:04:37
Bug Depends on:    
Bug Blocks: 42478    

Description Tobias Burnus 2009-01-26 18:32:46 UTC
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
Comment 1 Tobias Burnus 2009-01-26 18:42:09 UTC
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
Comment 2 Daniel Franke 2009-01-26 18:50:32 UTC
*** Bug 38947 has been marked as a duplicate of this bug. ***
Comment 4 Paul Thomas 2009-02-19 06:04:37 UTC
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
Comment 5 Arjen Verweij 2009-03-04 18:23:15 UTC
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?
Comment 6 Francois-Xavier Coudert 2009-03-29 09:11:15 UTC
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.
Comment 7 Tobias Burnus 2009-05-18 16:52:58 UTC
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
Comment 8 Arjen Verweij 2009-05-19 10:59:49 UTC
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
Comment 9 Matevz Tadel 2009-06-08 10:42:54 UTC
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.
Comment 10 Arjen Verweij 2009-12-01 15:10:25 UTC
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
Comment 11 Dominique d'Humieres 2015-10-30 17:58:13 UTC
Any progress after six years?
Comment 12 Dominique d'Humieres 2016-03-14 10:02:58 UTC
> Any progress after six years?

PING!
Comment 13 Dominique d'Humieres 2016-04-09 12:04:14 UTC
> > Any progress after six years?
>
> PING!

No feedback, closing as WONTFIX.