[Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2

[Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2

[patrick.marlier at gmail dot com]

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: unassigned@gcc.gnu.org
        ReportedBy: patrick.marlier@gmail.com
                CC: rth@gcc.gnu.org, aldyh@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_p<X>::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++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.02.15 15:36:35
     Ever Confirmed|0                           |1

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-02-15 15:36:35 UTC ---
[I'm waiting for Richard to comment on this.  This is from an email exchange. 
Recording here, so I don't lose track.]

This rather convoluted testcase, has us jumping through hoops that eventually
inline a GIMPLE_ASM into the virtual dispose() function.

When we do our initial scan of inline asms in the diagnose_tm_blocks pass,
inlining has not run, so we don't realize dispose() will eventually contain an
inline asm.

I'm this close to just adding a sanity pass through the BBs in the final tmmark
pass.  At least the source would be readable and maintainable.

How about instead of ICEing in expand_block_tm() when encountering inline asms,
we error out.  We have all the context we need to bitch that whatever the
inliner did was not right.  Or are you sure we could've forseen this ASM ahead
of time, so the gcc_unreachable() stands as is?

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-02-15 15:37:59 UTC ---
Created attachment 23351
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23351
further reduced testcase

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[patrick.marlier at gmail dot com]

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++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

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 #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-02-23 19:32:53 UTC ---
Patrick.

Ok, in that case we have two bugs.  Your original testcase ICEing on valid
code, and my incorrectly reduced testcase which is ICEing on invalid code.  

My incorrectly reduced code should complain about an unsafe function call
within a transaction_safe function.  It is correctly erroring at -O0, but
ICEing at any optimization.

Blah.  These inline + TM bugs just won't go away :(

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23243|0                           |1
        is obsolete|                            |
  Attachment #23351|0                           |1
        is obsolete|                            |

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-02-24 19:06:40 UTC ---
Created attachment 23458
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23458
Original testcase reduced (correctly with transaction_pure)

This testcase ICE's at -O2.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-02-24 19:08:36 UTC ---
Created attachment 23459
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23459
Additional ICE on incorrect code

At -O0 we get a correct diagnosis for this incorrect snippet:

b.c:15:4: error: unsafe function call 'GradientInfo::~GradientInfo()' within
'transaction_safe' function

But at >= -O1 we get an ICE:

b.c:13:15: internal compiler error: in expand_block_tm, at trans-mem.c:2333

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|aldyh at gcc dot gnu.org    |rth at gcc dot gnu.org

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> 2011-03-07 16:18:26 UTC ---
This is the gimple_asm inlining problem which rth has agreed to take over.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

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

--- Comment #8 from Richard Henderson <rth at gcc dot gnu.org> 2011-06-17 16:03:03 UTC ---
Fixed with:

2011-06-17  Richard Henderson  <rth@redhat.com>

        Backport from mainline
        2011-03-22  Richard Henderson  <rth@redhat.com>

        * dwarf2out.c (dwarf2out_frame_debug_expr) [rule 11]: Handle post_dec.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

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

--- Comment #9 from Richard Henderson <rth at gcc dot gnu.org> 2011-06-17 16:03:54 UTC ---
Gah.  Wrong PR.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW
         AssignedTo|rth at gcc dot gnu.org      |unassigned at gcc dot
                   |                            |gnu.org

--- Comment #10 from Richard Henderson <rth at gcc dot gnu.org> 2011-07-12 17:22:22 UTC ---
Not working on it atm.

[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2

[patrick.marlier at gmail dot com]

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