http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51830
Bug #: 51830 Summary: FAIL: libitm.c/mem(cpy|set)-1.c execution test Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: al...@gcc.gnu.org, hjl.to...@gmail.com, ia...@gcc.gnu.org, patrick.marl...@gmail.com Target: *86*-*-* >From pr51124 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51124#c9 ): libitm.c/memcpy-1.c and memset-1.c are still failing in 32 bit mode on *86*-*-*. From http://glutton.geoffk.org/HEAD/native-logsum/i686-pc-linux-gnu/libitm/testsuite/libitm.log.gzip , the failure is libitm: pr_undoLogCode not supported FAIL: libitm.c/memcpy-1.c execution test I also see that on x86_64-apple-darwin10. This comes from line 163 of libitm/beginend.cc // ??? pr_undoLogCode is not properly defined in the ABI. Are barriers // omitted because they are not necessary (e.g., a transaction on thread- // local data) or because the compiler thinks that some kind of global // synchronization might perform better? if (unlikely(prop & pr_undoLogCode)) GTM_fatal("pr_undoLogCode not supported"); See comments #11 to #14 in pr51124 for a discussion.