https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #11 from Domi
--- 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.
Thank
--- 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
--- 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 w
--- 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?
Is
--- 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
--- 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 trea
--- 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 gc
--- 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
--- 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
---
--- 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 dir
13 matches
Mail list logo
