From patchwork Wed Aug 3 11:57:34 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Torvald Riegel X-Patchwork-Id: 108135 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id BD714B71D5 for ; Wed, 3 Aug 2011 21:57:54 +1000 (EST) Received: (qmail 21643 invoked by alias); 3 Aug 2011 11:57:52 -0000 Received: (qmail 21633 invoked by uid 22791); 3 Aug 2011 11:57:52 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Aug 2011 11:57:37 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p73BvauW028061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 3 Aug 2011 07:57:37 -0400 Received: from [10.36.7.186] (vpn1-7-186.ams2.redhat.com [10.36.7.186]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p73BvZZA019126; Wed, 3 Aug 2011 07:57:35 -0400 Subject: [trans-mem] Test static constructors inside of transactional code From: Torvald Riegel To: GCC Patches Cc: Aldy Hernandez , Richard Henderson Date: Wed, 03 Aug 2011 13:57:34 +0200 Message-ID: <1312372654.3533.268.camel@triegel.csb> Mime-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Based on recent discussions among the C++ TM specification group, static constructors should be allowed in transactional (i.e., transaction_safe) code. GCC should have a wrapper assigment for __cxa_guard_acquire and __cxa_guard_release, and libitm should implement wrappers that guarantee atomicity of these constructors wrt the enclosing transaction. If we find out that supporting and implementing isn't feasible in practice, GCC should provide a better error message (eg, "static constructors not allowed in transactional code" instead of complaining about the __cxa* functions), and we should move this test to the GCC tests. OK for branch? commit 537788ae46aec7fcc45eee5ae56cfe3314a9ef11 Author: Torvald Riegel Date: Wed Aug 3 13:31:46 2011 +0200 Test static constructors inside of transactional code. * testsuite/libitm.c++/static_ctor.C: New file. diff --git a/libitm/testsuite/libitm.c++/static_ctor.C b/libitm/testsuite/libitm.c++/static_ctor.C new file mode 100644 index 0000000..f618f68 --- /dev/null +++ b/libitm/testsuite/libitm.c++/static_ctor.C @@ -0,0 +1,38 @@ +// { dg-do run } +/* Tests static constructors inside of transactional code. */ + +#include +#include + +int f(int x) __attribute__((noinline,transaction_safe)); +int f(int x) +{ + static int y = x; + return y*x; +} + +static void *thread (void *dummy __attribute__((unused))) +{ + int bar; + __transaction { bar = f(10); } + if (bar != 100) + abort(); + return 0; +} + +int main() +{ + int bar; + + // First, initialize y in another thread. + pthread_t pt; + pthread_create(&pt, NULL, thread, NULL); + pthread_join(pt, NULL); + + // Now y should already be initialized. + __transaction { bar = f(20); } + if (bar != 200) + abort(); + + return 0; +}