From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32142 invoked by alias); 8 Jun 2009 10:43:13 -0000 Received: (qmail 32055 invoked by uid 48); 8 Jun 2009 10:42:55 -0000 Date: Mon, 08 Jun 2009 10:43:00 -0000 Message-ID: <20090608104255.32054.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "matevz dot tadel at cern dot ch" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg00443.txt.bz2 ------- 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