[Bug fortran/38979] New: OpenMP extension:

[Bug fortran/38979] New: OpenMP extension:

[burnus at gcc dot gnu dot org]

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


-- 
           Summary: OpenMP extension:
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: openmp
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[burnus at gcc dot gnu dot org]

------- 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

[dfranke at gcc dot gnu dot org]

------- 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

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[burnus at gcc dot gnu dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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|0000-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

[arjen dot verweij at tass-safe dot com]

------- 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

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2009-03-29 09:11 -------
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.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|OpenMP extension:           |OpenMP extension:
                   |THREADPRIVATE for           |THREADPRIVATE for
                   |EQUIVALENCEd symbols        |EQUIVALENCEd symbols


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

[burnus at gcc dot gnu dot org]

------- 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

[arjen dot verweij at tass-safe dot com]

------- 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

[matevz dot tadel at cern dot ch]

------- 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

[arjen dot verweij at tass-safe dot com]

------- 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