From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28674 invoked by alias); 26 Jan 2009 18:42:23 -0000 Received: (qmail 28609 invoked by uid 48); 26 Jan 2009 18:42:09 -0000 Date: Mon, 26 Jan 2009 18:42:00 -0000 Message-ID: <20090126184209.28608.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: "burnus at gcc dot gnu dot org" 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-01/txt/msg02844.txt.bz2 ------- 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