From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14236 invoked by alias); 6 Apr 2011 19:54:58 -0000 Received: (qmail 14224 invoked by uid 22791); 6 Apr 2011 19:54:57 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Apr 2011 19:54:53 +0000 From: "brooks at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: brooks at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 06 Apr 2011 19:54:00 -0000 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: 2011-04/txt/msg00615.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Brooks Moses changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brooks at gcc dot gnu.org --- Comment #6 from Brooks Moses 2011-04-06 19:54:39 UTC --- It appears that this underlying issue will also affect C++0x support for thread-local storage, assuming that it also allows non-POD thread-local objects. (See links from http://gcc.gnu.org/projects/cxx0x.html.) This is also looking like it's going to be a significant problem for us in the near future in using OpenMP. Are there GLIBC and binutils issues filed for the necessary underlying functionality that Jakub mentions in comment 1? If so, what are they? If not, what additional information is needed to file a coherent and accurate feature request there?