diff mbox

[trans-mem] PR46941: Mark new/delete operators as transaction_pure

Message ID 4D35A768.5040108@unine.ch
State New
Headers show

Commit Message

Patrick Marlier Jan. 18, 2011, 2:44 p.m. UTC 
I am not agree. Functions should be marked as transaction_safe not 
transaction_pure because libitm is managing those new/delete safe 
allocations.

Attached one patch to fix this.

It causes a regression on
* testsuite/g++.dg/tm/pr45940-3.C
* testsuite/g++.dg/tm/pr45940-4.C

but it seems another problem, reported here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47340

Removing the transaction_safe declaration on these testcases make them pass.

Changelog

	* cp/decl.c (push_cp_library_fn): Mark function as
	transaction_safe.

On 01/12/2011 07:59 PM, Richard Henderson wrote:
> On 01/12/2011 10:38 AM, Aldy Hernandez wrote:
>> 	* cp/decl.c (push_cp_library_fn): Mark function as
>> 	transaction_pure.
>
> Ok.
>
>
> r~
>

Comments

Aldy Hernandez Feb. 2, 2011, 4:16 p.m. UTC | #1 
On 01/18/11 08:44, Patrick Marlier wrote:
> I am not agree. Functions should be marked as transaction_safe not
> transaction_pure because libitm is managing those new/delete safe
> allocations.

I don't think it matters, because from the point of view of the source 
being compiled, the new/delete can be executed inside a transaction 
without requiring any instrumentation or switching to serial irrevocable 
(thus it is a tm_pure function).  The fact that we rewrite the 
new/delete into a libitm call underneath it all is besides the point.

Thus, I don't think it matters either way.

Is there a sample that would be incorrectly executed if we use 
transaction_pure as I suggest?

Aldy
Aldy Hernandez Feb. 2, 2011, 4:38 p.m. UTC | #2 
On 02/02/11 10:16, Aldy Hernandez wrote:
> On 01/18/11 08:44, Patrick Marlier wrote:
>> I am not agree. Functions should be marked as transaction_safe not
>> transaction_pure because libitm is managing those new/delete safe
>> allocations.
>
> I don't think it matters, because from the point of view of the source
> being compiled, the new/delete can be executed inside a transaction
> without requiring any instrumentation or switching to serial irrevocable
> (thus it is a tm_pure function). The fact that we rewrite the new/delete
> into a libitm call underneath it all is besides the point.

Ok, I'm an idiot.  I understand now.  New/delete calls get handled by 
their transactional equivalents which are implemented in the libitm runtime.

By bad.  I will cook up a patch.

Thanks for your patience.
Aldy
diff mbox

Patch

Index: gcc/testsuite/g++.dg/tm/pr46941.C
===================================================================
--- gcc/testsuite/g++.dg/tm/pr46941.C	(revision 168943)
+++ gcc/testsuite/g++.dg/tm/pr46941.C	(working copy)
@@ -29,3 +29,7 @@ 
 { 
   delete [] o;
 }
+/* { dg-final { scan-assembler "_ZGTtnwm" } } */
+/* { dg-final { scan-assembler "_ZGTtnam" } } */
+/* { dg-final { scan-assembler "_ZGTtdlPv" } } */
+/* { dg-final { scan-assembler "_ZGTtdaPv" } } */
Index: gcc/cp/decl.c
===================================================================
--- gcc/cp/decl.c	(revision 168943)
+++ gcc/cp/decl.c	(working copy)
@@ -3776,7 +3776,7 @@ 
 				 type);
   pushdecl (fn);
   if (flag_tm)
-    apply_tm_attr (fn, get_identifier ("transaction_pure"));
+    apply_tm_attr (fn, get_identifier ("transaction_safe"));
   return fn;
 }