[Bug lto/66815] Segfault with -lto and libitm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66815 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com --- Created attachment 35936 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35936action=edit reduced testcase The .tm_clone_table section is not generated with LTO enabled. $ gcc -fgnu-tm -O0 -flto -c -o pr66815.o pr66815.c $ readelf -S pr66815.o | grep tm_clone_table So crt cannot notify TM clones to libitm.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #27 from Patrick Marlier patrick.marlier at gmail dot com --- I confirm that the patch fixes the performance problem that I had. I guess the patch is too complex to be backported. Thanks a lot Alexandre for the patch and to all for the deep analysis! (just waiting for review and commit :))
[Bug libitm/61594] ICE (assertion failure) in trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594 --- Comment #4 from Patrick Marlier patrick.marlier at gmail dot com --- GCC 4.8.3 and 4.9.1 still fail with an ICE. Please adjust the version in the PR and change the status. (I did not test 4.8.4 and 4.9.2 but I can test it).
[Bug target/64579] New: __TM_end __builtin_tend failed to return transactional state
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64579 Bug ID: 64579 Summary: __TM_end __builtin_tend failed to return transactional state Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: patrick.marlier at gmail dot com CC: bergner at gcc dot gnu.org Target: powerpc64 Created attachment 34433 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34433action=edit simple testcase __TM_end returns the transactional state before the instruction tend but the attached testcase fails. It is the same if we use __builtin_tend instead of the XL macro.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com --- The regression starts from this commit: trunk@200103 commit f82f0ea592c2d78077e03f5a1a3b9b40751cc116 Author: law law@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Jun 14 18:52:32 2013 + * gimple.h (gimple_can_coalesce_p): Prototype. * tree-ssa-coalesce.c (gimple_can_coalesce_p): New function. (create_outofssa_var_map, coalesce_partitions): Use it. * tree-ssa-uncprop.c (uncprop_into_successor_phis): Similarly. * tree-ssa-live.c (var_map_base_init): Use TYPE_CANONICAL if it's available. * gcc.dg/tree-ssa/coalesce-1.c: New test. And especially from this: gcc/tree-ssa-coalesce.c:gimple_can_coalesce_p (tree name1, tree name2) ... /* If the types are not the same, check for a canonical type match. This (for example) allows coalescing when the types are fundamentally the same, but just have different names. Note pointer types with different address spaces may have the same canonical type. Those are rejected for coalescing by the types_compatible_p check. */ if (TYPE_CANONICAL (t1) TYPE_CANONICAL (t1) == TYPE_CANONICAL (t2) types_compatible_p (t1, t2)) return true; But as Richard mentioned, I think the problem is in the RTL part.
[Bug ipa/64164] New: [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
Bug ID: 64164
Summary: [4.9/5 Regression] one more stack slot used due to one
less inlining level
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.marlier at gmail dot com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 34178
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34178action=edit
testcase
$ cc -O2 -S -o stm.s stm.c
$ cc -O2 -DOPT -S -o stm-opt.s stm.c
if you compare the 2 outputs, stm_load function is using one more slot on the
stack.
The difference is only this:
static inline size_t
AO_myload2(const volatile size_t *addr)
{
return *(size_t *)addr;
}
static inline size_t
AO_myload(const volatile size_t *addr)
{
#ifdef OPT
size_t result = AO_myload2(addr);
#else
size_t result = *(size_t *)addr;
#endif
return result;
}
Having one more inlined function should have the same optimization not a better
one.
4.8 does not have the problem and the code generated is the same.
[Bug c++/59131] Compiler segfaults while generating code to save local variables in transactional section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59131 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com --- Created attachment 33098 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33098action=edit reduced testcase
[Bug c++/59131] Compiler segfaults while generating code to save local variables in transactional section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59131 --- Comment #6 from Patrick Marlier patrick.marlier at gmail dot com --- This bug seems to be the same as this one: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 Maybe the patch can be backported to 4.7 (hopefully without breaking anything?).
[Bug libitm/61594] ICE (assertion failure) in trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594
--- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com ---
Created attachment 33058
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33058action=edit
reduced testcase
$ xgcc -Wall -Wextra -Wfatal-errors -O2 -fgnu-tm -S pr61594.c
pr61594.c: In function ‘fn1’:
pr61594.c:12:40: internal compiler error: in requires_barrier, at
trans-mem.c:1517
__attribute__((transaction_safe)) void fn1() { fn2(); }
[Bug libitm/61594] ICE (assertion failure) in trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||rth at gcc dot gnu.org --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com --- In requires_barrier, the tree is a TARGET_MEM_REF and the operand is a STRING_CST. Because STRING_CST is constant and cannot be modified, it does not need a barrier. So this could be solved like this: Index: gcc/trans-mem.c === --- gcc/trans-mem.c (revision 212229) +++ gcc/trans-mem.c (working copy) @@ -1512,7 +1512,7 @@ requires_barrier (basic_block entry_block, tree x, if (TREE_CODE (TMR_BASE (x)) != ADDR_EXPR) return true; x = TREE_OPERAND (TMR_BASE (x), 0); - if (TREE_CODE (x) == PARM_DECL) + if (TREE_CODE (x) == PARM_DECL || TREE_CODE (x) == STRING_CST) return false; gcc_assert (TREE_CODE (x) == VAR_DECL); /* FALLTHRU */ However I think that we should not instrument for all constants (INTEGER_CST, ...) and even for read-only. So I would prefer solving the issue like this: Index: gcc/trans-mem.c === --- gcc/trans-mem.c (revision 212229) +++ gcc/trans-mem.c (working copy) @@ -1512,7 +1512,7 @@ requires_barrier (basic_block entry_block, tree x, if (TREE_CODE (TMR_BASE (x)) != ADDR_EXPR) return true; x = TREE_OPERAND (TMR_BASE (x), 0); - if (TREE_CODE (x) == PARM_DECL) + if (TREE_CODE (x) == PARM_DECL || TREE_CONSTANT (x) || TREE_READONLY (x)) return false; gcc_assert (TREE_CODE (x) == VAR_DECL); /* FALLTHRU */ Note that 4.8 is also affected.
[Bug libitm/57855] passing unsafe function as transaction_safe function pointer does not generate error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57855 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail dot com --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com --- There was a related discussion here: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00598.html Probably we can modify Dave's patch a bit.
[Bug libitm/56801] Internal Compiler Error when compiling relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801 --- Comment #4 from Patrick Marlier patrick.marlier at gmail dot com --- Created attachment 30490 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30490action=edit reduced testcase. I am now able to reproduce the ICE even with FSF 4.7.3 (it was due to different included headers). Attached the preprocessed testcase. $ gcc-4.7 -O1 -fgnu-tm -pthread -S -Wall -Wfatal-errors testcase2.i testcase2.i: In function ‘foo’: testcase2.i:5:6: internal compiler error: in expand_call_tm, at trans-mem.c:2280
[Bug libitm/56801] Internal Compiler Error when compiling relaxed transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801 --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com --- This seems to be solved in 4.7.3 (I cannot reproduce). Mike, do you confirm that?
[Bug c/56572] GCC generates non-optimal transactional code when inlining nested transaction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||patrick.marlier at gmail ||dot com --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2013-03-10 15:35:43 UTC --- Please close http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56573 which is a duplicated bug report of this one.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #46 from Patrick Marlier patrick.marlier at gmail dot com 2013-02-08 11:46:33 UTC --- Jack, I am sorry to be picky but are dummy functions still required in libgcc/config/darwin-crt-tm.c? I haven't access to a machine with __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1060 to check that. In case I am completely wrong, just ignore this message. Thanks. -- Patrick
[Bug middle-end/53850] [4.8 Regression] ICE: in expand_call_tm, at trans-mem.c:2289 with -fgnu-tm -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53850 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||patrick.marlier at gmail ||dot com --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2012-08-20 20:27:18 UTC --- expand_call_tm fails because the memset builtin has no node associated to the decl. The problem here is that between tmipa and tmmark passes, some stores are replaced by a memset. However tmipa is supposed to transform the memset builtin to TM-aware memset (_ITM_memsetW). The solution I see is to postpone transformation of these builtins in tmmark pass.
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #9 from Patrick Marlier patrick.marlier at gmail dot com 2012-06-04 15:26:37 UTC --- Aldy, I have a testcase and a patch for this. I will submit it soon. Patrick
[Bug middle-end/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #11 from Patrick Marlier patrick.marlier at gmail dot com 2012-06-04 15:58:35 UTC --- Created attachment 27557 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27557 testcase (In reply to comment #10) Created attachment 27556 [details] propsed patch being tested Whoops, sorry Patrick. I already have a patch I am testing :). If you already have yours tested, feel free to submit it, otherwise I'll post shortly. Go ahead and submit (I will not able to do it before few hours). My patch was quite similar except for the testcase (using the tree dump but untested). Testcase attached if you want to include it into the testsuite.
[Bug ada/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 --- Comment #8 from Patrick Marlier patrick.marlier at gmail dot com 2012-05-22 15:58:53 UTC --- Aldy, Actually the problem is different that my first thought and it is a real bug. The problem is well described into the 'testcase for gcc testsuite'. In the testcase, you have a static function foo which is transaction_safe so a clone is created. This function foo is assigned to a transaction_safe function pointer and this function pointer is used in a transaction. However this tm-clone foo is never referenced so it is removed by ipa.c:cgraph_remove_unreachable_nodes(). One way to fix the problem is force the output of the clone as following: Index: trans-mem.c === --- trans-mem.c (revision 187371) +++ trans-mem.c (working copy) @@ -4330,7 +4330,8 @@ ipa_tm_create_version_alias (struct cgraph_node *n record_tm_clone_pair (old_decl, new_decl); - if (info-old_node-symbol.force_output) + if (info-old_node-symbol.force_output + || ipa_ref_list_first_referring (info-old_node-symbol.ref_list)) ipa_tm_mark_force_output_node (new_node); return false; } @@ -4383,7 +4384,8 @@ ipa_tm_create_version (struct cgraph_node *old_nod record_tm_clone_pair (old_decl, new_decl); cgraph_call_function_insertion_hooks (new_node); - if (old_node-symbol.force_output) + if (old_node-symbol.force_output + || ipa_ref_list_first_referring (old_node-symbol.ref_list)) ipa_tm_mark_force_output_node (new_node); /* Do the same thing, but for any aliases of the original node. */ However, I am not sure it is really the way to go. Probably we should add the references from the orginal function to the tm-clone? Thanks, Patrick
[Bug libitm/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 2012-05-15 22:23:54 UTC --- Created attachment 27412 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27412 testcase for gcc testsuite The problem is not into libitm. Attached a testcase for testsuite (gcc/testsuite/gcc.dg/tm/indirect-3.c). Note that with your patch, the tm testsuite fails. pr51516.C fails because the original function is output and not only the clone (only the clone is required). I am not sure the way to properly fix it. Thanks for having a look at the problem! -- Patrick Marlier
[Bug libitm/53008] abort in _ITM_getTMCloneSafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2012-04-27 15:00:16 UTC --- Hello Dave, This is because your mycompare function is not transaction_safe, so no clone can be found at runtime. So if you add transaction_safe to your comparison function, it should work. In your example it should be: __attribute__((transaction_safe)) static long mycompare(int a, int b) If it works, please closed the bug report. Thanks. -- Patrick Marlier
[Bug libitm/52526] libitm: stuck in futex_wait
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52526 --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2012-03-12 21:29:30 UTC --- Indeed, with your proposed patch, it fixes the problem. Thanks!
[Bug libitm/52526] New: libitm: stuck in futex_wait
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52526 Bug #: 52526 Summary: libitm: stuck in futex_wait Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: torv...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu libitm (default configuration/4.8.0 20120307) is stuck in futex_wait with STAMP kmeans with low contention and 8 threads. (gdb) info threads Id Target Id Frame 8Thread 0x7322b700 (LWP 24011) kmeans 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 7Thread 0x73a2c700 (LWP 24010) kmeans 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 6Thread 0x7422d700 (LWP 24009) kmeans 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 5Thread 0x74a2e700 (LWP 24008) kmeans 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 * 4Thread 0x7522f700 (LWP 24007) kmeans GTM::futex_wait (addr=0x77fdfbb8, val=1) at ../../../gcc-trunk/libitm/config/linux/futex.cc:49 3Thread 0x75a30700 (LWP 24006) kmeans 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 2Thread 0x76231700 (LWP 24005) kmeans 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 1Thread 0x773aa720 (LWP 24002) kmeans 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 (gdb) thread 5 [Switching to thread 5 (Thread 0x74a2e700 (LWP 24008))] #0 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 (gdb) bt #0 0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0 #1 0x00403099 in threadWait () #2 0x003ecb407b41 in start_thread () from /lib64/libpthread.so.0 #3 0x003eca8df49d in clone () from /lib64/libc.so.6 (gdb) thread 4 [Switching to thread 4 (Thread 0x7522f700 (LWP 24007))] #0 GTM::futex_wait (addr=0x77fdfbb8, val=1) at ../../../gcc-trunk/libitm/config/linux/futex.cc:49 49if (__builtin_expect (res == -ENOSYS, 0)) (gdb) bt #0 GTM::futex_wait (addr=0x77fdfbb8, val=1) at ../../../gcc-trunk/libitm/config/linux/futex.cc:49 #1 0x775cd1a4 in GTM::gtm_rwlock::read_lock (this=0x77fdfbb0, tx=0x7fffd40008c0) at ../../../gcc-trunk/libitm/config/linux/rwlock.cc:76 #2 0x775ccbfa in GTM::gtm_thread::decide_begin_dispatch (this=0x7fffd40008c0, prop=optimized out) at ../../../gcc-trunk/libitm/retry.cc:182 #3 0x775cc16b in GTM_begin_transaction (prop=41, jb=0x7522edb0) at ../../../gcc-trunk/libitm/beginend.cc:235 #4 0x775cd853 in _ITM_beginTransaction () at ../../../gcc-trunk/libitm/config/x86/sjlj.S:74 #5 0x004021ab in work () #6 0x0040308d in threadWait () #7 0x003ecb407b41 in start_thread () from /lib64/libpthread.so.0 #8 0x003eca8df49d in clone () from /lib64/libc.so.6
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #14 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-23 15:32:31 UTC --- (In reply to comment #9) (In reply to comment #8) This change bootstraps fine with current gcc trunk on x86_64-apple-darwin11. It almost fixes the failures in the boehm-gc test suite. The -m32 results always pass as... === boehm-gc Summary for unix/-m32 === # of expected passes12 # of unsupported tests1 but often the -m64 results show the failure... WARNING: program timed out. FAIL: boehm-gc.c/thread_leak_test.c -O2 execution test Running /sw/src/fink.build/gcc47-4.7.0-1/gcc-4.7-20120222/boehm-gc/testsuite/boehm-gc.lib/lib.exp ... === boehm-gc Summary for unix/-m64 === # of expected passes11 # of unexpected failures1 # of unsupported tests1 Are there any other darwin related changes upstream? I also notice this failure on x86_64 linux. In my case, it is due to the redefinition of GC_LINUX_THREADS. ./boehm-gc/include/gc_config.h:44:0: warning: GC_LINUX_THREADS redefined [enabled by default]^M ./boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:1:0: note: this is the location of the previous definition What does the log tell you?
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #16 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-23 15:49:26 UTC --- Created attachment 26735 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26735 proposal fix I have also started a patch (not tested at all) but I am more extreme in the approach and confines the change to boehm-gc and darwin x86/x86_64 (Lion doesn't support PPC, right?). Does the change to x86 is required? I am not sure... This is a workaround for 4.7 but I think boehm-gc should be updated for 4.8? Jack/Iain/Mike, I think it is wise to let you fix it since I have no access to a darwin11. PR boehm-gc/52179 * include/private/gcconfig.h (DARWIN): Define STACKBOTTOM with pthread_get_stackaddr_np when available. * configure.ac (THREADS): Check availability of pthread_get_stackaddr_np on *-*-darwin*. * configure: Regenerate.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179 --- Comment #22 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-23 18:52:56 UTC --- (In reply to comment #21) (In reply to comment #20) Where do you want the second change made? Let me repeat myself: the code is in boehm-gc/include/private/gcconfig.h, so the patch should change the ifdef DARWIN block there. In the code in the file I mentioned, as a replacement to the #define that exists today. Yes, See the reduced patch I posted in comment 17. Also, if thread_leak_test.c is twitchy with -pie at -m64, we could also open a PR for that and just skip this test on darwin11+ at -m64 for now. Assuming that my proposed reversion of r175182 causes no regressions in libjava on darwin11+. It seems there is already a PR for thread_leak_test.c failure: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 Patrick.
[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52179
Patrick Marlier patrick.marlier at gmail dot com changed:
What|Removed |Added
CC||patrick.marlier at gmail
||dot com
--- Comment #8 from Patrick Marlier patrick.marlier at gmail dot com
2012-02-22 22:30:52 UTC ---
As discussed in https://github.com/ivmai/bdwgc/issues/13, this was fixed in
boehm-gc but due to the stage 4, I don't expect to the boehm-gc version be
upgraded. Does a workaround should be proposed?
You can try that but 1) this is untested (and probably is not enough), 2)
NO_PTHREAD_GET_STACKADDR_NP macro does not exists in current boehm-gc so
probably it will create problems too.
Index: os_dep.c
===
--- os_dep.c(revision 184398)
+++ os_dep.c(working copy)
@@ -1011,6 +1011,14 @@ ptr_t GC_get_stack_base()
#if !defined(BEOS) !defined(AMIGA) !defined(MSWIN32) \
!defined(MSWINCE) !defined(OS2) !defined(NOSYS) !defined(ECOS)
+# if defined(DARWIN)
+/* We could use pthread_get_stackaddr_np even in case of a */
+/* single-threaded gclib (there is no -lpthread on Darwin). */
+# include pthread.h
+# undef STACKBOTTOM
+# define STACKBOTTOM (ptr_t)pthread_get_stackaddr_np(pthread_self())
+# endif /* defined(DARWIN) */
+
ptr_t GC_get_stack_base()
{
# if defined(HEURISTIC1) || defined(HEURISTIC2) || \
[Bug libitm/52042] libitm.c/clone-1.c (all darwin) and libitm.c/stackundo.c (darwin 11) execution tests fail with -fpie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52042 --- Comment #9 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-08 03:38:24 UTC --- Proposed fix here: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00321.html All comments (and tests) are welcome! Thanks.
[Bug middle-end/52047] [trans-mem] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2270) with -O -fgnu-tm -fprefetch-loop-arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52047 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-06 14:34:24 UTC --- Proposed fix here: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00096.html Waiting Rth approval and Aldy's kindness for commit. -- Patrick Marlier.
[Bug middle-end/52141] New: [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52141 Bug #: 52141 Summary: [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org Created attachment 26591 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26591 testcase ICE with -fgnu-tm -O1 In the continuation of PRs: 46269, 47606, 51443. ../../trunk-debug/gcc/xgcc -B ../../trunk-debug/gcc -fgnu-tm -O1 -S -o ICE-inline.s ICE-inline2.c ICE-inline2.c:2:13: warning: always_inline function might not be inlinable [-Wattributes] ICE-inline2.c:13:5: internal compiler error: in expand_block_tm, at trans-mem.c:2366 (gdb) bt ... #5 0x00b1714f in expand_block_tm (region=0x1b99160, bb=0x769aa208) at ../../trunk/gcc/trans-mem.c:2366 #6 0x00b17455 in execute_tm_mark () at ../../trunk/gcc/trans-mem.c:2467 #7 0x00a1672f in execute_one_pass (pass=0x196c0a0) at ../../trunk/gcc/passes.c:2081 ...
[Bug middle-end/52142] New: [trans-mem] inlined transaction_pure functions are instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52142 Bug #: 52142 Summary: [trans-mem] inlined transaction_pure functions are instrumented Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org Created attachment 26592 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26592 testcase with -fgnu-tm -O1 In this testcase, the function 'purefunc' has inline and transaction_pure attribute. In the optimized mode (-O), the function becomes inlined but also instrumented whereas it was annotated transaction_pure.
[Bug middle-end/52142] [trans-mem] inlined transaction_pure functions are instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52142 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-06 21:35:09 UTC --- Created attachment 26593 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26593 another testcase but with an asm statement the asm statement is in a transaction_pure function but diagnose a asm statement into an atomic transaction. $ ../gcc/xgcc -B/../gcc/ asm-2.c -fgnu-tm -O0 -S -o asm-2.s $ ../gcc/xgcc -B/../gcc/ asm-2.c -fgnu-tm -O1 -S -o asm-2.s asm-2.c:7:3: error: asm not allowed in atomic transaction
[Bug libitm/52042] libitm.c/clone-1.c (all darwin) and libitm.c/stackundo.c (darwin 11) execution tests fail with -fpie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52042 --- Comment #6 from Patrick Marlier patrick.marlier at gmail dot com 2012-02-07 04:02:08 UTC --- Created attachment 26595 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26595 patch that seems to work for clone-1.c Hi guys, In fact, the problem is that getsectdata doesn't take into account the PIE. We can use _dyld_get_image_vmaddr_slide(0) but it should not be correct in case of many dynamic libraries I guess. What do you think? Should I propose this patch? Patrick Marlier.
[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51916 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #7 from Patrick Marlier patrick.marlier at gmail dot com 2012-01-20 23:57:09 UTC --- Some more info: (gdb) bt #0 0x7fff884ec283 in exit () #1 0x000100e238fa in diagnostic_action_after_output (context=0x141397020, diagnostic=0x7fff5fbfee80) at ../../trunk/gcc/diagnostic.c:243 #2 0x000100e2477d in diagnostic_report_diagnostic (context=0x141397020, diagnostic=0x7fff5fbfee80) at ../../trunk/gcc/diagnostic.c:552 #3 0x000100e2589b in internal_error (gmsgid=0x100f076ef in %s, at %s:%d) at ../../trunk/gcc/diagnostic.c:845 #4 0x000100e25a35 in fancy_abort (file=Could not find the frame base for fancy_abort. ) at ../../trunk/gcc/diagnostic.c:899 #5 0x000100c72b41 in streamer_get_builtin_tree (ib=0x7fff5fbff070, data_in=0x1419126a0) at ../../trunk/gcc/tree-streamer-in.c:1077 #6 0x000100853d12 in lto_input_tree (ib=0x7fff5fbff070, data_in=0x1419126a0) at ../../trunk/gcc/lto-streamer-in.c:1175 #7 0x0001000368f3 in lto_read_decls (decl_data=0x141f45000, data=0x1420ac410, resolutions=0x0) at ../../trunk/gcc/lto/lto.c:925 #8 0x00010003740c in lto_file_finalize (file_data=0x141f45000, file=0x141903a10) at ../../trunk/gcc/lto/lto.c:1167 #9 0x00010003744d in lto_create_files_from_ids (file=0x141903a10, file_data=0x141f45000, count=0x7fff5fbff204) at ../../trunk/gcc/lto/lto.c:1177 #10 0x000100037553 in lto_file_read (file=0x141903a10, resolution_file=0x0, count=0x7fff5fbff204) at ../../trunk/gcc/lto/lto.c:1217 #11 0x00010003f5ec in read_cgraph_and_symbols (nfiles=2, fnames=0x14190f300) at ../../trunk/gcc/lto/lto.c:2618 #12 0x000100040008 in lto_main () at ../../trunk/gcc/lto/lto.c:2932 #13 0x0001009e7f29 in compile_file () at ../../trunk/gcc/toplev.c:557 #14 0x0001009ead90 in do_compile () at ../../trunk/gcc/toplev.c:1938 #15 0x0001009eaf15 in toplev_main (argc=17, argv=0x1419003c0) at ../../trunk/gcc/toplev.c:2014 #16 0x00010004324e in main (argc=16, argv=0x7fff5fbff2b8) at ../../trunk/gcc/main.c:36 Fails as before the fcode corresponding to the TM_COMMIT. The problem is that the lto-wrapper does not collect parameters from input files. The tracing brings me into libiberty, we see that simple_object_start_read returns NULL with obj_0 or obj_1. Breakpoint 1, run_gcc (argc=4, argv=0x7fff5fbff598) at ../../trunk/gcc/lto-wrapper.c:482 482 sobj = simple_object_start_read (fd, file_offset, NULL, errmsg, err); (gdb) p argv[i] $2 = 0x7fff5fbff751 obj_0.o (gdb) n 483 if (!sobj) (gdb) p sobj $3 = (simple_object_read *) 0x0 Tracing a bit more, I see that simple_object_mach_o_match() ends with this: *errmsg = Mach-O file found but no segment name specified; Indeed, lto-wrapper always gives NULL for the segment name. sobj = simple_object_start_read (fd, file_offset, NULL, errmsg, err); So, since there is no documentation/specification of the simple_object_start_read function I cannot say if it is a gcc/lto bug or a libiberty bug. Finally, there is a problem with lto-wrapper.c if (!simple_object_find_section (sobj, LTO_SECTION_NAME_PREFIX . opts, offset, length, errmsg, err)) In MacOSX, I don't know the section name for opts (I have __wrapper_index, __wrapper_sects, and __wrapper_names) but if I add the segment name __GNU_LTO , the section name is .gnu.lto_.opts (not existing in my files). To sum up, LTO files with MacOS does not supported opts or cannot be retrieve in lto-wrapper. Need inputs from MacOS (and maybe LTO) maintainers... Thanks! Patrick Marlier.
[Bug rtl-optimization/51771] trans-mem: abnormal edges get lost or corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2012-01-17 22:09:58 UTC --- Just to not forget, one thread about it is here: http://gcc.gnu.org/ml/gcc/2012-01/msg00099.html Patrick Marlier.
[Bug other/51124] libitm failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124 --- Comment #11 from Patrick Marlier patrick.marlier at gmail dot com 2012-01-09 14:27:18 UTC --- libitm.c/memcpy-1.c and memset-1.c are still failing in 32 bit mode on *86*-*-*. Fix proposed here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01784.html Torvald, what was decided about the API?
[Bug other/51124] libitm failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124 --- Comment #13 from Patrick Marlier patrick.marlier at gmail dot com 2012-01-09 15:22:45 UTC --- As posted here http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01804.html, GCC explicitly change the calling convention to stdcall when variable arguments in x86/32 bits mode. So I am sure a calling convention document specifies that even if I cannot find it.
[Bug c++/48075] infinite loop when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 2012-01-09 15:49:12 UTC --- Invalid.
[Bug middle-end/51252] FAIL: c-c++-common/tm/freq.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #10 from Patrick Marlier patrick.marlier at gmail dot com 2012-01-09 15:55:52 UTC --- What's the status of this report? Do all libitm tests passed on PA? Does it still not working on Tru64 UNIX? Thanks.
[Bug other/51124] libitm failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124 --- Comment #14 from Patrick Marlier patrick.marlier at gmail dot com 2012-01-09 16:52:47 UTC --- From http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html regparm (number) ... Functions that take a variable number of arguments will continue to be passed all of their arguments on the stack. From IRC: Do you know if variadic function and regparm(2) are compatible on x86/32? Quoting ktietz: no they aren't (at least for IA-32). As variadic functions require reserved-stack-region, as va_list is in fact a stack-pointer for this target. there might be case variadic could work, but these are exceptions. It depends on signature. For regparm(2) the varidic would need to be at the 4th argument, as va_start need prior argument to get proper stack-location. But this is just a special-case. it is a consequence of the way variadic is defined for IA-32 targets. if calling-conventions using register(s) for argument passing, we would need to know amount of variable part on runtime to calculate stack-clone region for it. In fact this would be for IA-32 possible, if function has pascal argument ordering. The variadic-args vs. regparm(2) issue is the blocker for memcpy-1.c/memset-1.c. No clue for clone-1.c since I cannot reproduce. The eh-1.C on darwin seems to be a problem with XCode 4+ (http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html). Probably a different PR should be filled. Patrick.
[Bug c/51696] New: [trans-mem] unsafe indirect function call in struct not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51696 Bug #: 51696 Summary: [trans-mem] unsafe indirect function call in struct not properly displayed Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, torv...@gcc.gnu.org Created attachment 26196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26196 Attached testcase With an unsafe indirect function call, the error message is not clear. I don't know if it can display the declaration. In the worst case, unsafe indirect function call within ‘transaction_safe’ function should be ok. $ ./gcc/xgcc -B./gcc/ -fgnu-tm -O0 testcase.i testcase.i: In function ‘func’: testcase.i:7:21: error: unsafe function call ‘Uf3c0’ within ‘transaction_safe’ function testcase.i:8:12: error: unsafe function call ‘compare.1’ within ‘transaction_safe’ function Patrick Marlier.
[Bug lto/51698] New: [trans-mem] TM runtime and application with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51698 Bug #: 51698 Summary: [trans-mem] TM runtime and application with LTO Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org, torv...@gcc.gnu.org Created attachment 26198 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26198 testcase app-itm with lto In my attempt to make _ITM_R/W* calls inlined into the application code, it seems that the TM builtins and TM defintions don't work as expected with LTO. $ gcc -flto -fgnu-tm -Wall -o bin appitm.c `_ITM_beginTransaction' referenced in section `.text' of /tmp/cc7uGSe1.ltrans0.ltrans.o: defined in discarded section `.text' of /tmp/ccJk2crp.o (symbol from plugin) `_ITM_RU4' referenced in section `.text' of /tmp/cc7uGSe1.ltrans0.ltrans.o: defined in discarded section `.text' of /tmp/ccJk2crp.o (symbol from plugin) `_ITM_commitTransaction' referenced in section `.text' of /tmp/cc7uGSe1.ltrans0.ltrans.o: defined in discarded section `.text' of /tmp/ccJk2crp.o (symbol from plugin) collect2: error: ld returned 1 exit status I have merged all .c in the same source for the testcase but it has the same problem if TM runtime is in a library. Patrick Marlier.
[Bug middle-end/51516] New: [trans-mem] problem with TM clone aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51516 Bug #: 51516 Summary: [trans-mem] problem with TM clone aliases Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org Created attachment 26060 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26060 patch for trans-mem.c PR51347 shows up a problem due to the TM IPA rework. Indeed, an alias can get called but tm cg data are in the parent of the alias. So it ends up to calls _ITM_getTMCloneOrIrrevocable for the alias which is wrong. Patch attached with testcase. Bootstrapped and regtested. http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00225.html Patrick Marlier.
[Bug lto/51280] ICE when lto1 does not have -fgnu-tm and object file uses TM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 --- Comment #3 from Patrick Marlier patrick.marlier at gmail dot com 2011-12-10 03:35:38 UTC --- Created attachment 26040 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26040 testcase for gnu-tm Well, I don't know why I can't reproduce it for openmp. I will try to have a look at it next week. At least, attached the testcase for trans-mem. $ ./xgcc -B. -fgnu-tm -flto -c lto.c -o lto.o $ ./xgcc -B. -flto -o lto lto.o lto1: internal compiler error: in streamer_get_builtin_tree, at tree-streamer-in.c:1056 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: ./xgcc returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status Patrick.
[Bug middle-end/51443] New: [trans-mem] internal compiler error in expand_block_tm of trans-mem.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51443 Bug #: 51443 Summary: [trans-mem] internal compiler error in expand_block_tm of trans-mem.c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org, torv...@gcc.gnu.org Created attachment 26011 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26011 testcase with -gnu-tm -O1 I report this bug which is very close to some previous one (PR46269/PR47606). In this testcase, it fails to detect the block as irrevocable due to the asm and thus failed in expand_block_tm. Actually the way to mark a block irrevocable in a transaction_callable is a bit obscure to me. Thanks. Patrick Marlier.
[Bug c++/51347] [trans-mem] Segfault on templates with -O1 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51347 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2011-12-03 02:24:12 UTC --- Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00225.html Thanks for reporting! Patrick Marlier.
[Bug c++/48075] infinite loop when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075 --- Comment #4 from Patrick Marlier patrick.marlier at gmail dot com 2011-12-03 03:53:02 UTC --- Created attachment 25976 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25976 reduced and without transaction relaxed I am hesitating to mark it as invalid since limiting the template-depth seems to show the error. I let C++ guru if they think it is invalid (limit depth to 4 but it is quadratic expansion). Patrick Marlier. $ g++ inf.C -O0 -ftemplate-depth=4 inf.C:7:31: error: template instantiation depth exceeds maximum of 4 (use -ftemplate-depth= to increase the maximum) instantiating ‘class listlistlistlistlistint::Building*, allocatorlistint::Building* ::Building*, allocatorlistlistint::Building*, allocatorlistint::Building* ::Building* ::Building*, allocatorlistlistlistint::Building*, allocatorlistint::Building* ::Building*, allocatorlistlistint::Building*, allocatorlistint::Building* ::Building* ::Building* ::Building*, allocatorlistlistlistlistint::Building*, allocatorlistint::Building* ::Building*, allocatorlistlistint::Building*, allocatorlistint::Building* ::Building* ::Building*, allocatorlistlistlistint::Building*, allocatorlistint::Building* ::Building*, allocatorlistlistint::Building*, allocatorlistint::Building* ::Building* ::Building* ::Building* ’ inf.C:7:31: recursively required from ‘class listlistint::Building*, allocatorlistint::Building* ’ inf.C:7:31: required from ‘class listint’ inf.C:12:12: required from here
[Bug middle-end/51273] ICE: vector VEC(inline_summary_t,base) index domain error, in inline_summary at ipa-inline.h:193 with -O -fgnu-tm, transaction_safe and overloaded contructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51273 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2011-11-28 01:06:09 UTC --- Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02460.html Thanks for reporting. Patrick Marlier.
[Bug lto/51280] ICE when lto1 does not have -fgnu-tm and object file uses TM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2011-11-23 18:53:04 UTC --- Created attachment 25904 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25904 testcase Of course this bug also affect openMP. (see testcase)
[Bug lto/51280] New: ICE when lto1 does not have -fgnu-tm and object file uses TM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280
Bug #: 51280
Summary: ICE when lto1 does not have -fgnu-tm and object file
uses TM
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: al...@gcc.gnu.org, dnovi...@gcc.gnu.org,
rgue...@gcc.gnu.org, r...@gcc.gnu.org,
torv...@gcc.gnu.org
LTO should display a error message to indicate that gnu-tm is not enabled and
not ICE.
lto1: internal compiler error: in streamer_get_builtin_tree, at
tree-streamer-in.c:1056
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
1051 if (fclass == BUILT_IN_NORMAL)
1052{
1053 if (fcode = END_BUILTINS)
1054fatal_error (machine independent builtin code out of range);
1055 result = builtin_decl_explicit (fcode);
1056 gcc_assert (result);
1057}
(gdb) p fcode
$2 = BUILT_IN_TM_COMMIT
(gdb) bt
#0 fancy_abort (file=0x12b2168 ../../trunk/gcc/tree-streamer-in.c,
line=1056, function=0x12b2250 streamer_get_builtin_tree)
at ../../trunk/gcc/diagnostic.c:899
#1 0x00c4f5ea in streamer_get_builtin_tree (ib=0x7fffd760,
data_in=0x1a273d0) at ../../trunk/gcc/tree-streamer-in.c:1056
#2 0x008b5aeb in lto_input_tree (ib=0x7fffd760, data_in=0x1a273d0)
at ../../trunk/gcc/lto-streamer-in.c:1148
#3 0x004b052a in lto_read_decls (decl_data=0x769b9000,
data=0x1a36970, resolutions=0x1a26320) at ../../trunk/gcc/lto/lto.c:902
#4 0x004b0e25 in lto_file_finalize (file_data=0x769b9000,
file=0x19944a0) at ../../trunk/gcc/lto/lto.c:1140
#5 0x004b0e72 in lto_create_files_from_ids (file=0x19944a0,
file_data=0x769b9000, count=0x7fffd8ec) at
../../trunk/gcc/lto/lto.c:1150
#6 0x004b0f8b in lto_file_read (file=0x19944a0,
resolution_file=0x1a25460, count=0x7fffd8ec) at
../../trunk/gcc/lto/lto.c:1190
#7 0x004b8095 in read_cgraph_and_symbols (nfiles=1, fnames=0x19af0f0)
at ../../trunk/gcc/lto/lto.c:2591
#8 0x004b87da in lto_main () at ../../trunk/gcc/lto/lto.c:2905
#9 0x009ffe99 in compile_file () at ../../trunk/gcc/toplev.c:565
#10 0x00a021a9 in do_compile () at ../../trunk/gcc/toplev.c:1931
#11 0x00a02314 in toplev_main (argc=17, argv=0x197d2e0) at
../../trunk/gcc/toplev.c:2007
#12 0x004bb7c4 in main (argc=17, argv=0x7fffda68) at
../../trunk/gcc/main.c:36
To reproduce, compile file with transactions and lto, and link without -flto.
Patrick.
[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 2011-11-19 17:42:20 UTC --- ** NOT RELATED TO BUG ** In http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00969.html, the patch shows changes to tree-ssa-reassoc.c but not committed or part of Changelog. But the problem is definitely not here. Patrick. Index: tree-ssa-reassoc.c === --- tree-ssa-reassoc.c.orig2011-11-07 15:56:25.0 +0100 +++ tree-ssa-reassoc.c2011-11-07 16:12:35.0 +0100 @@ -2869,6 +2869,12 @@ reassociate_bb (basic_block bb) rhs1 = gimple_assign_rhs1 (stmt); rhs2 = gimple_assign_rhs2 (stmt); + /* We don't want to destroy reduction like patterns + with reassociation, simply don't start at such + statements. */ + if (is_phi_for_stmt (stmt, rhs1) || is_phi_for_stmt (stmt, rhs2)) +continue; + /* For non-bit or min/max operations we can't associate all types. Verify that here. */ if (rhs_code != BIT_IOR_EXPR
[Bug middle-end/51211] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242) with -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1 and __transaction_atomic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51211 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2011-11-18 18:11:56 UTC --- This seems to solve the issue but we need to figure out why we get _ITM_RU here. Thanks for reporting :) Patrick Marlier. Index: trans-mem.c === --- trans-mem.c (revision 181466) +++ trans-mem.c (working copy) @@ -2211,6 +2211,9 @@ if (fn_decl == builtin_decl_explicit (BUILT_IN_TM_MEMSET)) transaction_subcode_ior (region, GTMA_HAVE_STORE); + if (flags_from_decl_or_type (fn_decl) ECF_TM_BUILTIN) +return false; + if (is_tm_pure_call (stmt)) return false;
[Bug middle-end/51211] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242) with -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1 and __transaction_atomic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51211
--- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com
2011-11-18 22:52:44 UTC ---
After looking at it. I guess the problem was in the tracer...
The tracer tries to duplicate the BB where the __transaction_atomic is.
Unfortunately this is not valid with trans-mem passes. Either duplicate all
blocks of the transaction or forbid the duplicate of the block. I choose the
second one.
Patrick Marlier.
Index: gcc/tracer.c
===
--- gcc/tracer.c(revision 181425)
+++ gcc/tracer.c(working copy)
@@ -90,10 +90,14 @@
static bool
ignore_bb_p (const_basic_block bb)
{
+ gimple g;
if (bb-index NUM_FIXED_BLOCKS)
return true;
if (optimize_bb_for_size_p (bb))
return true;
+ g = last_stmt (CONST_CAST_BB (bb));
+ if (g gimple_code (g) == GIMPLE_TRANSACTION)
+return true;
return false;
}
[Bug middle-end/51130] ICE: in create_tmp_var, at gimplify.c:468 with -fgnu-tm and __transaction_atomic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51130 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2011-11-17 02:34:11 UTC --- Probably the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125. Thanks for the reduced testcase. Patrick Marlier.
[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #3 from Patrick Marlier patrick.marlier at gmail dot com 2011-11-17 02:34:03 UTC --- Probably the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51130 (which include reduced testcase). Patrick Marlier.
[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||torvald at gcc dot gnu.org Resolution||FIXED --- Comment #11 from Patrick Marlier patrick.marlier at gmail dot com 2011-11-02 15:40:48 UTC --- The latest version (probably thanks to Richard's code revision 180635) seems to fix the ICE. But one question with attachment 23459, at -O0 we get a unsafe function call error but not at -O1. So my question : is it safe to have 2 different results depending on the optimization level? Also, I don't know if those testcases should be included in the tm testsuite. Patrick Marlier. g++ -O0 -fgnu-tm -c b1.c b1.c:15:4: error: unsafe function call ‘GradientInfo::~GradientInfo()’ within ‘transaction_safe’ function g++ -O1 -fgnu-tm -c b1.c
[Bug lto/50964] New: [trans-mem] no support for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50964 Bug #: 50964 Summary: [trans-mem] no support for LTO Classification: Unclassified Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: al...@gcc.gnu.org, r...@gcc.gnu.org, torv...@gcc.gnu.org Created attachment 25690 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25690 generate ICE A simple test (attached) shows that LTO does not support TM (GIMPLE_TRANSACTION). gcc -O0 -fgnu-tm -flto test.c -o test.o test.c: In function ‘main’: test.c:10:1: internal compiler error: in output_gimple_stmt, at gimple-streamer-out.c:155 Please submit a full bug report, with preprocessed source if appropriate. Patrick Marlier.
[Bug tree-optimization/48625] [trans-mem] Segfault in libitm when compiling with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48625 --- Comment #3 from Patrick Marlier patrick.marlier at gmail dot com 2011-05-03 12:06:13 UTC --- The problem is that _ITM_beginTransaction shouldn't have caller save optimization because if the transaction aborts, registers will get random values. It should be ok for others ITM functions. I fixed it by adding RETURN_TWICE attribute to BUILT_IN_TM_START as a workaround but I know it shouldn't be fixed like this. I had a look into gcc sources but I didn't find the right way to fix it. By the way, if a user wants to use explicit calls to _ITM_ functions to create its TM program, _ITM_beginTransaction should have a specific attribute to avoid caller save optimization. In the same way, the tail call optimization must be forbidden on _ITM_commitTransaction. How should it be managed? Patrick Marlier.
[Bug tree-optimization/48625] [trans-mem] Segfault in libitm when compiling with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48625 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||rth at gcc dot gnu.org --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2011-05-02 15:18:26 UTC --- The problem is with caller-save pass. I didn't figure out why (bug in caller-save? or should we forbid caller-save on _ITM_* functions?). Maybe Richard and Aldy have an idea? You can disable this pass with -fno-caller-saves, it should work. Patrick Marlier.
[Bug tree-optimization/48625] [trans-mem] Segfault in libitm when compiling with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48625 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added CC||patrick.marlier at gmail ||dot com --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2011-04-28 16:19:37 UTC --- Hi Martin, libitm is unfortunately buggy... Did you try it with another STM like TinySTM? So we can try to figure out if it is miscompiled or run-time bug. Patrick Marlier.
[Bug c++/48075] [trans-mem] infinite loop when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075 --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2011-03-31 07:26:24 UTC --- Created attachment 23833 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23833 same testcase but with errors removed (In reply to comment #1) Can you reduce this test case again without the errors? Attached the same testcase but with errors removed. Patrick Marlier.
[Bug c++/48074] [trans-mem] regular function used instead of clone in a transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48074 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added Severity|normal |critical
[Bug c++/48074] New: [trans-mem] regular function used instead of clone in a transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48074 Summary: [trans-mem] regular function used instead of clone in a transaction Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23631 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23631 not so big testcase. In a relaxed transaction, some functions (stl? template?) in an transaction doesn't call the clone version (not in an irrevocable mode: neither attribute doesGoIrrevocable nor ITM_changeTransactionMode). You can verify this in the function stepDestroyBuildings (_ZL20stepDestroyBuildingsi) in Team.cpp (from glob2, kind of testcase attached), the function _ZNSt4listIP8BuildingSaIS1_EE5beginEv is called directly (not the clone, no changeTransactionMode) even if in a transaction. I had a quick look and the clone function exists but the call seems not be replaced. It seems to happen when one transaction is followed by another one (at least related). Patrick Marlier.
[Bug c++/48075] New: [trans-mem] infinite loop when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075 Summary: [trans-mem] infinite loop when compiling Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23632 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23632 infinite calls testcase. An infinite loop happens with the attached testcase. Maybe not related to trans-mem specifically... Here the backtrace: #10225 0x0050b680 in instantiate_class_template (type=0x76b20e70) at ../../transactional-memory/gcc/cp/pt.c:7965 #10226 0x005740b7 in complete_type (type=0x76b20e70) at ../../transactional-memory/gcc/cp/typeck.c:130 #10227 0x004de334 in tsubst_decl (t=0x76bd31e0, args=0x76b1f090, complain=3) at ../../transactional-memory/gcc/cp/pt.c:9533 #10228 0x004e96d0 in tsubst (t=0x76bd31e0, args=0x76b1f090, complain=3, in_decl=0x0) at ../../transactional-memory/gcc/cp/pt.c:9912 #10229 0x0050b680 in instantiate_class_template (type=0x76b200a8) at ../../transactional-memory/gcc/cp/pt.c:7965 #10230 0x005740b7 in complete_type (type=0x76b200a8) at ../../transactional-memory/gcc/cp/typeck.c:130 #10231 0x004de334 in tsubst_decl (t=0x76bd31e0, args=0x76b1c4b0, complain=3) at ../../transactional-memory/gcc/cp/pt.c:9533 #10232 0x004e96d0 in tsubst (t=0x76bd31e0, args=0x76b1c4b0, complain=3, in_decl=0x0) at ../../transactional-memory/gcc/cp/pt.c:9912 #10233 0x0050b680 in instantiate_class_template (type=0x76b1b2a0) at ../../transactional-memory/gcc/cp/pt.c:7965 #10234 0x005740b7 in complete_type (type=0x76b1b2a0) at ../../transactional-memory/gcc/cp/typeck.c:130 #10235 0x004de334 in tsubst_decl (t=0x76bd31e0, args=0x76b198d0, complain=3) at ../../transactional-memory/gcc/cp/pt.c:9533 #10236 0x004e96d0 in tsubst (t=0x76bd31e0, args=0x76b198d0, complain=3, in_decl=0x0) at ../../transactional-memory/gcc/cp/pt.c:9912 ... Patrick Marlier.
[Bug c++/47952] [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 --- Comment #12 from Patrick Marlier patrick.marlier at gmail dot com 2011-03-10 14:19:35 UTC --- On 03/10/2011 12:01 AM, rth at gcc dot gnu.org wrote: I suspect, but have not yet verified, that this is related to // Inhibit implicit instantiations for required instantiations, // which are defined via explicit instantiations elsewhere. // NB: This syntax is a GNU extension. #if _GLIBCXX_EXTERN_TEMPLATE 0 extern template class basic_stringchar; in that we're copying the is extern bit, which is not true for the transactional clone. I don't know if it is related but I have another bug which may be related with template. In a relaxed transaction, some functions (stl? template?) in a transaction doesn't call the clone version (nor call to ITM_changeTransactionMode). You can verify this in the function stepDestroyBuildings (_ZL20stepDestroyBuildingsi) in src/Tean.cpp, the function _ZNSt4listIP8BuildingSaIS1_EE5beginEv is called directly (not the clone, no irrevocable mode) even if in a transaction. I had a quick look and the clone function exists but seems not be replaced (the begin attribute doesn't say irrevocable and no changeMode). It seems to happen when one transaction is followed by another one (Not sure if it is the cause) I would like to have a look at it but I will be on vacation next week and I have to finish urgent things... (I have added Aldy as CC since he also has glob2 and it might interest him) Should I fill a new PR for this even if I don't have any real testcase? Thanks. Patrick.
[Bug c++/47952] [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 --- Comment #11 from Patrick Marlier patrick.marlier at gmail dot com 2011-03-10 04:31:30 UTC --- This issue has been filled here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48021 There is also a reduced testcase. (If I remember well the namespace std matters). Patrick. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48021 On Thu, Mar 10, 2011 at 12:01 AM, rth at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 --- Comment #10 from Richard Henderson rth at gcc dot gnu.org 2011-03-09 23:01:38 UTC --- The remaining problem in the full glob2 test is src/Unit.o: In function `transaction clone for Unit::~Unit()': Unit.cpp:(.text._ZGTtN4UnitD2Ev[transaction clone for Unit::~Unit()]+0x2c): undefined reference to `transaction clone for std::basic_stringchar, std::char_traitschar, std::allocatorchar ::~basic_string()' collect2: ld returned 1 exit status which really really doesn't exist. No amount of marking this function weak is going to work. I suspect, but have not yet verified, that this is related to // Inhibit implicit instantiations for required instantiations, // which are defined via explicit instantiations elsewhere. // NB: This syntax is a GNU extension. #if _GLIBCXX_EXTERN_TEMPLATE 0 extern template class basic_stringchar; in that we're copying the is extern bit, which is not true for the transactional clone. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug c++/47952] [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 --- Comment #6 from Patrick Marlier patrick.marlier at gmail dot com 2011-03-08 10:17:58 UTC --- Created attachment 23582 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23582 testcase from glob2. With the committed patch and this attached testcase, we get this .text._ZGTtNSt14_List_iteratorIN4Game12BuildProjectEEC2EPSt15_List_node_base,axG,@progbits,_ZGTt67_ZNSt14_List_iteratorIN4Game12BuildProjectEEC5EPSt15_List_node_base,comdat instead of .text._ZGTtNSt14_List_iteratorIN4Game12BuildProjectEEC2EPSt15_List_node_base,axG,@progbits,_ZGTtNSt14_List_iteratorIN4Game12BuildProjectEEC5EPSt15_List_node_base,comdat Patrick Marlier.
[Bug c++/48021] New: [trans-mem] call to an undefined clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48021 Summary: [trans-mem] call to an undefined clone Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23569 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23569 testcase showing that. In this testcase, the std namespace is not transactionalized and a class, Unit is using implicit destructor std::string for its member. In this class Unit, the destructor is cloned but the implicit destructor for std::string is transformed to a transactional one _ZGTtNSsD2Ev. Unfortunately, _ZGTtNSsD2Ev is not defined and I think the correct behaviour should be switching to irrevocable mode and then call the unsafe _ZNSsD2Ev. Aldy: this happens in the Glob2, one undefined reference that we got. Patrick Marlier.
[Bug c/48023] New: [trans-mem] no-builtin flag and TM builtin like memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48023 Summary: [trans-mem] no-builtin flag and TM builtin like memset Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23574 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23574 testcase for memset. If -fgnu-tm and -fno-builtin are used, code is transactified but then the memset becomes unsafe. I think the behavior is correct but I just want to be sure. So don't hesitate to mark it as invalid. $ gcc -fno-builtin -fgnu-tm -S -O0 testcase.i testcase.i:10:8: error: unsafe function call ‘memcpy’ within ‘transaction_safe’ function $ gcc -fgnu-tm -S -O0 testcase.i Patrick Marlier.
[Bug c++/47952] New: [trans-mem] undefined reference to transaction clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47952 Summary: [trans-mem] undefined reference to transaction clone Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org, javier.ar...@bsc.es Created attachment 23513 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23513 attached almost reduced testcase. An undefined reference to a transaction clone appears at link time. $ g++ -save-temps -O0 -c -Wall -fgnu-tm testcase.i testcase.o:(.tm_clone_table+0x8): undefined reference to `transaction clone for std::_List_iteratorGame::BuildProject::_List_iterator(std::_List_node_base*)' The testcase is not completely reduced... I will post it a better one soon. Considered it as high priority since it happens in the Velox stack. Thanks :) Patrick.
[Bug c/47905] New: [trans-mem] ipa_tm_decrement_clone_counts ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47905 Summary: [trans-mem] ipa_tm_decrement_clone_counts ICE Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org, javier.ar...@bsc.es Created attachment 23478 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23478 reduced testcase. Regression caused by revision 170213 It works with r170142. Attached a reduced testcase. $ gcc -O0 -fgnu-tm testcase.i testcase.i: In function âthreadâ: testcase.i:11:1: internal compiler error: in ipa_tm_decrement_clone_counts, at trans-mem.c:3789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Please consider it at the highest priority since it happens with the Velox Stack. Patrick Marlier.
[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 --- Comment #3 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-15 15:59:37 UTC --- (In reply to comment #2) Created attachment 23351 [details] further reduced testcase Remark: In this testcase, you removed the __attribute__((transaction_pure)) which was making the asm statement legal in a transaction.
[Bug c++/47746] New: [trans-mem] invalid conversion in gimple call, ICE verify_stmts failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47746 Summary: [trans-mem] invalid conversion in gimple call, ICE verify_stmts failed Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23347 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23347 testcase with O0 GCC raises an ICE into verify_stmts. Attached a reduced testcase. Thanks Patrick Marlier $ g++ -fgnu-tm -S -O0 invalid_conversion.i invalid_conversion.i: In member function ‘void Building::load(InputStream*)’: invalid_conversion.i:24:1: error: invalid conversion in gimple call unsigned int int D.2242_4 = D.2249_9 (stream_1(D)); invalid_conversion.i:24:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/47747] New: [trans-mem] unsafe virtual function not properly displayed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47747 Summary: [trans-mem] unsafe virtual function not properly displayed Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23348 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23348 testcase that shows the error If a virtual function is not annotated as transaction safe and called in a transaction safe function, gcc raises an unsafe function error but it doesn't print correctly the function name. $ g++ -fgnu-tm -S -O0 unsafe_virtual.i unsafe_virtual.i: In constructor ‘Building::Building(InputStream*)’: unsafe_virtual.i:17:30: error: unsafe function call ‘#‘obj_type_ref’ not supported by dump_decl#declaration error’ within ‘transaction_safe’ function Attached a testcase. Patrick Marlier.
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #4 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-10 09:39:05 UTC --- I hope next time to come up with a 'perfect' patch! Thanks for the explanation and for the fix. :) Patrick.
[Bug c/47689] New: [trans-mem] function is cloned even if not used in transaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47689 Summary: [trans-mem] function is cloned even if not used in transaction Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23304 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23304 testcase for testsuite that show this problem The function NewQueueNode is cloned (_ZGTt12NewQueueNode) whereas there is no need to transactify it.
[Bug c/47690] New: [trans-mem] ICE in verify_cgraph_node with O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47690 Summary: [trans-mem] ICE in verify_cgraph_node with O0 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23305 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23305 testcase that raises the problem with O0 GCC raises an ICE in verify_cgraph_node with O0. $ gcc -O0 -S -fgnu-tm testcase.i testcase.i:14:1: error: edge points to wrong declaration: function_decl 0x7f4c52291300 NewQueueNode type function_type 0x7f4c52242150 type void_type 0x7f4c52340e70 void VOID align 8 symtab 0 alias set -1 canonical type 0x7f4c52340e70 pointer_to_this pointer_type 0x7f4c52340f18 QI size integer_cst 0x7f4c5232e730 constant 8 unit size integer_cst 0x7f4c5232e758 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7f4c5235ff18 pointer_to_this pointer_type 0x7f4c522421f8 addressable public static tm-clone decl_5 QI file testcase.i line 7 col 6 align 8 initial block 0x7f4c52247160 abstract_origin function_decl 0x7f4c52244000 NewQueueNode result result_decl 0x7f4c52245180 D.2897 type void_type 0x7f4c52340e70 void used ignored VOID file testcase.i line 7 col 6 align 8 context function_decl 0x7f4c52291300 NewQueueNode abstract_origin result_decl 0x7f4c52245000 D.1705 struct-function 0x7f4c5241e720 Instead of: function_decl 0x7f4c52244000 NewQueueNode type function_type 0x7f4c52242150 type void_type 0x7f4c52340e70 void VOID align 8 symtab 0 alias set -1 canonical type 0x7f4c52340e70 pointer_to_this pointer_type 0x7f4c52340f18 QI size integer_cst 0x7f4c5232e730 constant 8 unit size integer_cst 0x7f4c5232e758 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7f4c5235ff18 pointer_to_this pointer_type 0x7f4c522421f8 addressable public static decl_5 QI file testcase.i line 7 col 6 align 8 initial block 0x7f4c52247000 result result_decl 0x7f4c52245000 D.1705 type void_type 0x7f4c52340e70 void ignored VOID file testcase.i line 7 col 6 align 8 context function_decl 0x7f4c52244000 NewQueueNode (mem:QI (symbol_ref:DI (NewQueueNode) [flags 0x3] function_decl 0x7f4c52244000 NewQueueNode) [0 S1 A8]) struct-function 0x7f4c5241e688 NewQueueNode/2(-1) @0x7f4c52339750 availability:available 62 time, 10 benefit 14 size, 1 benefit needed reachable body externally_visible finalized called by: NewQueueNode/2 (1.00 per call) calls: __builtin__ITM_commitTransaction/1 (1.00 per call) NewQueueNode/2 (1.00 per call) testcase.i:14:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Summary: [trans-mem] internal compiler error in expand_block_tm with O2 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23243 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23243 old testcase flavoured I wanted to reopen this old bug but I can't since I am not the creator: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269 Anyway, here a test case that raised again this with O2: $ g++ -fgnu-tm -S -O2 -Wfatal-errors ICE_expand_block_tm.i ICE_expand_block_tm.i: In member function ‘void sp_counted_impl_pX::dispose() [with X = GradientInfo]’: ICE_expand_block_tm.i:31:15: internal compiler error: in expand_block_tm, at trans-mem.c:2323 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It seems that even if the function atomic_exchange_and_add is declared transaction_pure, gcc complains about the GIMPLE_ASM statement in expand_block_tm. Patrick Marlier.
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #10 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-04 13:54:30 UTC --- (In reply to comment #8) I will tackle the ECF_MALLOC comment separately. Should I open up a new bug report for this? or is it already on your TODO list? Patrick Marlier.
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #13 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-04 20:13:04 UTC --- Hi Aldy, On Fri, Feb 4, 2011 at 7:40 PM, aldyh at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #12 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-02-04 18:40:09 UTC --- Patrick, the reason memory allocated by the C++ new operator does not get optimized by the TM-memopt pass is not because of a missing ECF_MALLOC attribute, but because the alias oracle in GCC considers the chunk of memory as possibly able to escape from the current function. I have added the malloc attribute to the declaration of the new operator and it worked so I though this was it. After this I found a discussion about adding malloc attribute to new operator... That is, the following hunk of code returns true in the TM-memopt pass: if (ptr_deref_may_alias_global_p (x)) Apparently, since new/delete operators may be overridden by class specific hooks, the memory must be considered escaped. Hum I see. But if the new/delete operators are not overridden then the returned memory could be marked as transaction local, right? Otherwise at least a comment somewhere is welcome to be aware of this behavior. So, this is not a TM bug, but a feature of the alias oracle in GCC. Actually, this was not a bug but an improvement (why using costly write barriers on transaction local memory). As usual, thanks ;) Patrick.
[Bug c++/47611] New: [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611 Summary: [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org This is an improvement with a *LOW* priority. Only if spare time (hey could be a nice homework). See comments in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #15 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-04 20:30:15 UTC --- Filled a enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47611Yeah don't lose time of this! On Fri, Feb 4, 2011 at 9:16 PM, aldyh at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #14 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-02-04 20:16:07 UTC --- Yes, this is an improvement, because once has to figure out why the unadultered new operator is not handled specially by the alias oracle. You are welcome to file a PR as an enhancement request, but honestly I won't get to it anytime soon, because of the other critical problems with the toolchain. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug other/46567] [trans-mem] ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567 --- Comment #7 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-03 10:28:37 UTC --- Created attachment 23234 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23234 new testcase with O0 Here a reduced test case that raises this ICE with current svn version: $ gcc -O0 -S -fgnu-tm ICE_ipa_tm_propagate_irr.i ICE_ipa_tm_propagate_irr.i: In function ‘readLoop’: ICE_ipa_tm_propagate_irr.i:23:1: internal compiler error: in ipa_tm_decrement_clone_counts, at trans-mem.c:3763 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. and raises this ICE with Andrew's patch (tm2.patch) gcc -O0 -S -fgnu-tm ICE_ipa_tm_propagate_irr.i ICE_ipa_tm_propagate_irr.i: In function ‘readLoop’: ICE_ipa_tm_propagate_irr.i:23:1: internal compiler error: in ipa_tm_propagate_irr, at trans-mem.c:3738 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Thanks. Patrick Marlier.
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 Patrick Marlier patrick.marlier at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #7 from Patrick Marlier patrick.marlier at gmail dot com 2011-02-02 14:17:23 UTC --- (In reply to comment #6) Fixed http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00776.html Please considered this... http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01206.html It must be **transaction_safe** not transaction_pure. Moreover I think we should also add ECF_MALLOC (malloc attribute) because otherwise the allocated memory will not be considered as local. Extract from trans-mem.c: thread_private_new_memory() if (stmt is_gimple_call (stmt) gimple_call_flags (stmt) ECF_MALLOC) /* Thread-local or transaction-local. */ ; else retval = mem_non_local; Thanks.
[Bug c++/47573] New: [trans-mem] ICE in invoke_set_current_function_hook
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47573 Summary: [trans-mem] ICE in invoke_set_current_function_hook Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 23199 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23199 testcase boom The attached test case makes GCC crashed (with latest revision 169442). $ g++ -fgnu-tm -O0 -S testcase.i testcase.i:22:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program received signal SIGSEGV, Segmentation fault. invoke_set_current_function_hook (fndecl=0xa5a5a5a5a5a5a5a5) at ../../transactional-memory/gcc/function.c:4039 4039 ? DECL_FUNCTION_SPECIFIC_OPTIMIZATION (fndecl) (gdb) bt #0 invoke_set_current_function_hook (fndecl=0xa5a5a5a5a5a5a5a5) at ../../transactional-memory/gcc/function.c:4039 #1 0x00aca463 in verify_cgraph_node (node=0x76bbdc30) at ../../transactional-memory/gcc/cgraphunit.c:581 #2 0x00acadd8 in verify_cgraph () at ../../transactional-memory/gcc/cgraphunit.c:812 #3 0x00aee65b in cgraph_remove_unreachable_nodes (before_inlining_p=1 '\001', file=0x0) at ../../transactional-memory/gcc/ipa.c:306 #4 0x008427ee in execute_todo (flags=384) at ../../transactional-memory/gcc/passes.c:1307 #5 0x00844e5a in execute_one_pass (pass=0x132f6c0) at ../../transactional-memory/gcc/passes.c:1602 #6 0x0084525a in execute_ipa_pass_list (pass=0x132f6c0) at ../../transactional-memory/gcc/passes.c:1813 #7 0x00acd5a7 in ipa_passes () at ../../transactional-memory/gcc/cgraphunit.c:1796 #8 cgraph_optimize () at ../../transactional-memory/gcc/cgraphunit.c:1831 #9 0x00acdf35 in cgraph_finalize_compilation_unit () at ../../transactional-memory/gcc/cgraphunit.c:1096 #10 0x005393cb in cp_write_global_declarations () at ../../transactional-memory/gcc/cp/decl2.c:3837 #11 0x008ea23a in compile_file (argc=15, argv=0x7fffe4c8) at ../../transactional-memory/gcc/toplev.c:1065 #12 do_compile (argc=15, argv=0x7fffe4c8) at ../../transactional-memory/gcc/toplev.c:2424 #13 toplev_main (argc=15, argv=0x7fffe4c8) at ../../transactional-memory/gcc/toplev.c:2466 #14 0x76f95d8e in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fffe4b8) at libc-start.c:226 #15 0x00489089 in _start ()
[Bug c/47530] New: [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 Summary: [trans-mem] tail call optimization problem with _ITM_commitTransaction Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org According to: http://gcc.gnu.org/ml/gcc/2011-01/msg00314.html http://gcc.gnu.org/ml/gcc/2011-01/msg00279.html The tail call optimization should not be possible on _ITM_commitTransaction because this function can go (longjmp) to _ITM_beginTransaction and thus the stack will be corrupted. Here ASM: _function: pushq %r12 pushq %rbp pushq %rbx subq$16, %rsp ... call_ITM_beginTransaction .L8: ... call_ITM_WU8 addq$16, %rsp popq%rbx popq%rbp popq%r12 jmp _ITM_commitTransaction In this example, if _ITM_commitTransaction rolls back to L8, the function epilogue will restore wrong values to registers (modified by the function _ITM_commitTransaction) when leaving the _function. Moreover I think that the function _ITM_beginTransaction should have the flag ECS_RETURNS_TWICE because it is how it behaves (ie the transaction can abort and longjmp behind the _ITM_beginTransaction call). Draft patch proposed in http://gcc.gnu.org/ml/gcc/2011-01/msg00279.html Patrick Marlier.
[Bug other/46567] [trans-mem] ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 2011-01-28 14:18:45 UTC --- Created attachment 23153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23153 testcase with O0 With this testcase and -O0: $ gcc -fgnu-tm -O0 -S pr46567-2.i -o testcase.s pr46567-2.i: In function ‘readLoop’: pr46567-2.i:18:1: internal compiler error: in ipa_tm_decrement_clone_counts, at trans-mem.c:3748 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Maybe not related to this bug?
[Bug c/47520] New: [trans-mem] ICE Segmentation fault at 01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47520 Summary: [trans-mem] ICE Segmentation fault at 01 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org, javier.ar...@bsc.es Created attachment 23155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23155 testcase with O1 Hi, Reporting a bug found using RMSTM benchmark and optimization level 1. Attached a reduced test case. gcc -fgnu-tm -O1 -S hmmer-2.i hmmer-2.i: In function ‘ReadSeq’: hmmer-2.i:26:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Patrick.
[Bug c/47492] [trans-mem] Problem with memset() inside transaction_safe function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47492 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2011-01-27 15:10:18 UTC --- Created attachment 23143 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23143 draft patch This patch makes it work but: (trans-mem.c) examine_call_tm(): I don't know if it is require to test for BUILT_IN_TM_MEMSET because it is never reached. expand_call_tm(): it is required to mark the transaction having transactional stores but should it be also done for MEMCPY/MEMMOVE?
[Bug c++/47340] New: [trans-mem] problem with declaration of new operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47340 Summary: [trans-mem] problem with declaration of new operator Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org It seems that there is a problem with the declaration of new operator and related to PR46941. Attached the testcase. $ g++ -I . -save-temps -fgnu-tm -c -o incomplete3.o incomplete3.cpp ... incomplete3.cpp:31:67: error: call to function ‘void* operator new(long unsigned int)’ which throws incomplete type ‘struct std::bad_alloc’ Patrick Marlier.
[Bug c++/47340] [trans-mem] problem with declaration of new operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47340 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2011-01-18 13:47:21 UTC --- Created attachment 23019 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23019 testcase
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #3 from Patrick Marlier patrick.marlier at gmail dot com 2010-12-23 15:45:15 UTC --- Actually, I was guessing that the patch was not intrusive. Wrong guess, play again... I should really spend more time on hacking gcc ;) Anyway, Thank you for your advices! (I will follow them next time!) About the bug itself, I will not have time to look at it these days.
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 2010-12-23 16:27:47 UTC --- Aldy. I think you should declare it 'transaction_safe' and not 'transaction_pure' since symbols in the libitm are binded to safe: _ZGTtnwm; _ZGTtnam; _ZGTtdlPv; _ZGTtdaPv; _ZGTtnwmRKSt9nothrow_t; _ZGTtnamRKSt9nothrow_t; _ZGTtdlPvRKSt9nothrow_t; _ZGTtdaPvRKSt9nothrow_t;
[Bug c++/46941] [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 --- Comment #1 from Patrick Marlier patrick.marlier at gmail dot com 2010-12-22 10:11:54 UTC --- Created attachment 22839 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22839 proposed patch to add safe attribute to new delete operators gcc/cp/decl.c: build_library_fn_1() add transaction_safe attribute to new/delete/new []/delete [] declarations if transaction mode is enabled. Patrick Marlier.
[Bug c++/46646] [trans-mem] __cxa_rethrow and __builtin_eh_pointer are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46646 --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2010-12-14 11:13:15 UTC --- Created attachment 22751 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22751 testcase .ii I will try to make a shorter one soon.
[Bug c++/46941] New: [trans-mem] new/delete operator are unsafe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46941 Summary: [trans-mem] new/delete operator are unsafe Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 22754 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22754 testcase for new delete The new/delete are not considered safe even if GCC managed and replaced to transaction_safe ones. g++ -fgnu-tm -Wall -o newdelete newdelete.cpp newdelete.cpp:38:13: error: unsafe function call ‘void operator delete [](void*)’ within ‘transaction_safe’ function newdelete.cpp:32:19: error: unsafe function call ‘void* operator new [](long unsigned int)’ within ‘transaction_safe’ function newdelete.cpp:26:11: error: unsafe function call ‘void operator delete(void*)’ within ‘transaction_safe’ function newdelete.cpp:20:14: error: unsafe function call ‘void* operator new(long unsigned int)’ within ‘transaction_safe’ function
[Bug c++/46653] [trans-mem] ICE with volatile int in transactional constructor using -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46653 --- Comment #2 from Patrick Marlier patrick.marlier at gmail dot com 2010-11-29 13:34:36 UTC --- Created attachment 22563 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22563 testcase ICE with volatile int in transactional constructor using -O1 Sorry, I don't why it was not uploaded...
[Bug c++/46714] New: [trans-mem] built-in aliased to undefined symbol with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46714 Summary: [trans-mem] built-in aliased to undefined symbol with -O1 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org Created attachment 22571 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22571 testcase for this bug. There is a strange error when there is a weak_ref. g++ -O1 -o aliased_undef_sym.o -c -Wall -fgnu-tm aliased_undef_sym.cpp aliased_undef_sym.cpp:13:1: error: ‘built-in’ aliased to undefined symbol ‘_ZGTtN8BuildingD2Ev’
[Bug c++/46653] New: [trans-mem] ICE with volatile int in transactional constructor using -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46653 Summary: [trans-mem] ICE with volatile int in transactional constructor using -O1 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org gcc -Wall -c -O1 -fgnu-tm ice_volatile.cpp -o ice_volatile ice_volatile.cpp: In function ‘int main()’: ice_volatile.cpp:12:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Patrick Marlier.
[Bug c++/46654] New: [trans-mem] volatile objects must not be allowed in a safe statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46654 Summary: [trans-mem] volatile objects must not be allowed in a safe statement Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org In the Draft transactional construct for C++, volatile object are not allowed in a safe statement (section 3.2). In the current implementation, there is no warning or error raised by the compiler. gcc -Wall -c -fgnu-tm volatile.c -o volatile - No error Attached the testcase. Patrick Marlier.
