[Bug c++/46269] New: [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[Bug c++/46269] New: [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[vincent.gramoli at epfl dot ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

           Summary: [trans-mem] internal compiler error in expand_block_tm
                    of trans-mem.c
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vincent.gramoli@epfl.ch


I encounter the following problem when trying to compile transaction-based
Globulation2 (attached is the .ii):

gramoliv@gramoliv-desktop:~/svn/velox/trunk/glob2$ g++ -o src/Building.o -c
-Wall --gnu-tm -fno-builtin -DHAVE_CONFIG_H -D_GNU_SOURCE=1 -D_REENTRANT
-Ilibgag/include -I. -I/usr/include/SDL src/Building.cpp
In file included from src/Building.cpp:28:0:
src/Building.h:69:143: warning: ‘transaction_unknown’ attribute directive
ignored
In file included from src/Building.cpp:34:0:
src/Unit.h:52:81: warning: ‘transaction_unknown’ attribute directive ignored
In file included from src/Building.cpp:34:0:
src/Unit.h:174:37: warning: ‘transaction_unknown’ attribute directive ignored
src/Building.cpp: In member function ‘void Building::updateCallLists()’:
src/Building.cpp:907:6: warning: suggest explicit braces to avoid ambiguous
‘else’
src/Building.cpp: In member function ‘void Building::updateUnitsHarvesting()’:
src/Building.cpp:1153:82: warning: suggest parentheses around comparison in
operand of ‘&’
src/Building.cpp: In member function ‘bool
Building::subscribeToBringRessourcesStep()’:
src/Building.cpp:1708:8: warning: unused variable ‘teamNumber’
src/Building.cpp:1734:8: warning: unused variable ‘teamNumber’
src/Building.cpp: In member function ‘bool
Building::subscribeForFlagingStep()’:
src/Building.cpp:1940:11: warning: unused variable ‘canSwim’
src/Building.cpp:1801:8: warning: unused variable ‘teamNumber’
src/Building.cpp:1875:9: warning: unused variable ‘map’
src/Building.cpp: In member function ‘bool Building::canConvertUnit()’:
src/Building.cpp:2818:39: warning: comparison between signed and unsigned
integer expressions
src/Building.cpp:2819:24: warning: comparison between signed and unsigned
integer expressions
In file included from
/usr/include/boost/smart_ptr/detail/sp_counted_base.hpp:36:0,
                 from /usr/include/boost/smart_ptr/detail/shared_count.hpp:29,
                 from /usr/include/boost/smart_ptr/shared_ptr.hpp:32,
                 from /usr/include/boost/shared_ptr.hpp:17,
                 from src/Order.h:36,
                 from src/Building.h:29,
                 from src/Building.cpp:28:
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp: In function
‘int boost::detail::atomic_exchange_and_add(int*, int)’:
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:35:12: internal
compiler error: in expand_block_tm, at trans-mem.c:2199

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
            Version|unknown                     |trans-mem
           Severity|blocker                     |normal

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2010.11.03 16:29:30
     Ever Confirmed|0                           |1

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2010-11-03 16:29:30 UTC ---
There is no attached .ii.

Can you please attach one, and could you also try to reduce the testcase as
much as possible?  The more you reduce it, the easier it is to fix :).

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[patrick.marlier at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

--- Comment #2 from Patrick Marlier <patrick.marlier at gmail dot com> 2010-11-04 14:31:04 UTC ---
Created attachment 22281
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22281
small test case

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
         AssignedTo|unassigned at gcc dot       |aldyh at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2010-11-09 17:36:00 UTC ---
The problem here is that for the inline function atomic_exchange_and_add(), the
user is expecting the transaction_pure to be implied because the caller
(BuildingCompletedEvent::BuildingCompletedEvent) is marked as transaction_pure.

GCC doesn't see this implied transaction_pure, so we call
ipa_tm_transform_clone() to make a clone of atomic_exchange_and_add.  Later,
when we try to expand the transaction in the atomic_exchange_and_add() clone,
we fail in expand_block_tm() because we don't handle GIMPLE_ASM's.

Richard, is the implied transaction_pure legal, and so we should handle it?  Or
should we exit gracefully in expand_block_tm() with an error about not
supporting inline asms in a transaction?

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[rth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

--- Comment #4 from Richard Henderson <rth at gcc dot gnu.org> 2010-11-09 18:06:35 UTC ---
Since updateBuildingSite is transaction_callable, not 
transaction_safe, we should handle this no matter how
the other functions are annotated.

When atomic_exchange_and_add is not annotated, we should
transition to serial-irrevocable mode before the asm,
just as we would do when calling any other unknown function.

When atomic_exchange_and_add is annotated pure, we should
believe it and not process anything inside.  We do not
currently support a general TM escape mechanism on a per-
block basis, so the only way to really ignore stuff inside
transaction_pure functions is to *not* inline them.

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[patrick.marlier at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

--- Comment #5 from Patrick Marlier <patrick.marlier at gmail dot com> 2010-11-10 09:39:16 UTC ---
Since currently there is no support for general TM escape block, I think it is
a workaround that needs to be changed when this support will be added.

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2010-11-11 15:46:10 UTC ---
I have submitted a fix here:

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01078.html

I have also submitted a fix for the additional ICE mentioned in the testcase
("XXX Commenting the line below creates another segfault") here:

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01167.html

Both are pending approval, so the PR remains open.

[Bug c++/46269] [trans-mem] internal compiler error in expand_block_tm of trans-mem.c

[aldyh at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46269

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2010-11-17 16:43:02 UTC ---
Fixed on branch in aforementioned threads.