When I compile a transactional program which use an annotated STL, GCC compilation says that the function is not safe even if it is annotated. I have attached the ii file (I tried to make it smaller but it didn't figure out when it happens). Here the compilation: $ g++ -O0 -c -Wall -g -fgnu-tm -fno-builtin Building.ii In file included from src/Building.cpp:77:0: src/Building.cpp:1341:27: error: unsafe function call ‘void std::list<_Tp, _Alloc>::push_front(const value_type&) [with _Tp = Bullet*, _Alloc = std::allocator<Bullet*>, value_type = Bullet*]’ within ‘transaction_safe’ function Extract from STL source: __attribute__((transaction_pure)) void push_front(const value_type& __x) { this->_M_insert(begin(), __x); }
Created attachment 22282 [details] .ii file same file as sent by email few time ago.
Mine
I have a patch to fix this problem, but I also see that the provided testcase has another error message which I think is correct: In file included from src/Building.cpp:77:0: src/Building.cpp:56:34: error: unsafe function call 'void std::list<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = Building*, _Alloc = std::allocator<Building*>, value_type = Building*]' within 'transaction_safe' function push_back() is not annotated as transaction_pure. Please verify that this is the case on your end, because my upcoming patch will only fix the error in the PR, not this additional error I see.
(In reply to comment #3) > push_back() is not annotated as transaction_pure. True. It was just a annotation test and thus others functions are not annotated. So it seems correct. > Please verify that this is the case on your end, because my upcoming patch will > only fix the error in the PR, not this additional error I see. I think it is ok. Did you send the patch in gcc-patches? Patrick Marlier.
Fixed by: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02354.html Waiting for approval.
Created attachment 22526 [details] another testcase It seems not completely solved. Here a another testcase. With -O0, it complains about unsafe function even if annotated as transaction_pure. gcc -Wall -c -O0 -fgnu-tm unsafe.cpp -o unsafe unsafe.cpp:38:54: error: unsafe function call ‘int atomic_exchange_and_add(int*, int)’ within ‘transaction_safe’ function With -O1, ICE in expand_block_tm(). gcc -Wall -c -O1 -fgnu-tm unsafe.cpp -o unsafe unsafe.cpp: In function ‘int main()’: unsafe.cpp:73:5: internal compiler error: in expand_block_tm, at trans-mem.c:2254 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Vincent, please reopen the bug and in the bug description set version to "trans-mem" (easier to find it). Patrick Marlier.
As Patrick has written above, there is still an issue.
This fixes the -O0 case. Pending approval. http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02803.html
The -O1 ICE is due to the fact that we have an inline function that has been marked as transaction_pure, but contains an inline asm. The following code sets the 'saw_unsafe' bit, regardless of the transaction_pure attribute: case GIMPLE_ASM: /* ??? We ought to come up with a way to add attributes to asm statements, and then add "transaction_safe" to it. Either that or get the language spec to resurrect __tm_waiver. */ if (d->block_flags & DIAG_TM_SAFE) error_at (gimple_location (stmt), "asm not allowed in atomic transaction"); else if (d->func_flags & DIAG_TM_SAFE) error_at (gimple_location (stmt), "asm not allowed in %<transaction_safe%> function"); else d->saw_unsafe = true; break; The easy way to solve this, is to pass the fndecl in d->, and check for transaction_pure attributes. The hard way, is to add attributes to asm statements (see comment above), mark asm statements as safe/pure when appropriate, and never loose this information. You can guess which way I want to solve it. Richard?
[offline rth notes] In function_attribute_inlinable_p, if fndecl is tm_pure and current_function_decl is tm_safe, deny the inlining. This is because tm_pure is the only escape hatch we have for "do not annotate this". E.g. you want to add a call to printf for debugging, or there's some data you know that shouldn't be part of the transaction. The fix for this is to implement __tm_waiver. But you know yourself how tricky getting just the transaction blocks correct has been. Adding holes within the region is... nasty. But probably required eventually. In inline_forbidden_p_stmt, notice asms and prevent them from being inlined if current_function_decl is tm_safe. This will stop early inlining from breaking tm_safe functions when dealing with e.g. system header files that include inline asms.
Fixed on mainline, but I will leave the PR open until a more thorough fix is committed.
Properly fixed here; awaiting approval. http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01003.html
I updated and got the following problem while recompiling. Could it be related to your recent changes somehow? gcc -o gnupg/sha1.o -c -DHAVE_CONFIG_H -D_GNU_SOURCE=1 -D_REENTRANT -Ilibgag/include -I. -I/usr/include/SDL gnupg/sha1.c ar rc gnupg/libgnupg.a gnupg/sha1.o ranlib gnupg/libgnupg.a g++ -o libgag/src/BinaryStream.o -c -Wall -g -fgnu-tm -fno-builtin -DHAVE_CONFIG_H -D_GNU_SOURCE=1 -D_REENTRANT -Ilibgag/include -I. -I/usr/include/SDL libgag/src/BinaryStream.cpp In file included from /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/localefwd.h:42:0, from /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:45, from libgag/include/Stream.h:25, from libgag/include/BinaryStream.h:23, from libgag/src/BinaryStream.cpp:20: /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/i686-pc-linux-gnu/bits/c++locale.h: In function ‘int std::__convert_from_v(int* const&, char*, int, const char*, ...)’: /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/i686-pc-linux-gnu/bits/c++locale.h:65:24: error: call to function ‘void* operator new [](unsigned int)’ which throws incomplete type ‘struct std::bad_alloc’ In file included from /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/valarray:87:0, from libgag/src/BinaryStream.cpp:22: /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/valarray_array.h: In function ‘void* std::__valarray_get_memory(size_t)’: /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/valarray_array.h:53:28: error: call to function ‘void* operator new(unsigned int)’ which throws incomplete type ‘struct std::bad_alloc’ In file included from /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/valarray:564:0, from libgag/src/BinaryStream.cpp:22: /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/gslice.h: In constructor ‘std::gslice::gslice()’: /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/gslice.h:148:35: error: call to function ‘void* operator new(unsigned int)’ which throws incomplete type ‘struct std::bad_alloc’ /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/gslice.h: In constructor ‘std::gslice::gslice(size_t, const std::valarray<unsigned int>&, const std::valarray<unsigned int>&)’: /home/gramoli/velox/gcc-tm-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/gslice.h:153:48: error: call to function ‘void* operator new(unsigned int)’ which throws incomplete type ‘struct std::bad_alloc’
Vincent, this is bug 47340. I will be looking at this today.
Thanks! Vincent On Jan 20, 2011, at 3:31 PM, aldyh at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940 > > --- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-01-20 14:30:50 UTC --- > Vincent, this is bug 47340. I will be looking at this today. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug.
Hi Aldy, The bug does you refer to does not seem to be assigned to anyone. Vincent On Jan 20, 2011, at 3:31 PM, aldyh at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940 > > --- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-01-20 14:30:50 UTC --- > Vincent, this is bug 47340. I will be looking at this today. > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug.