[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

2022-01-31 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||marxin at gcc dot gnu.org

--- Comment #9 from Martin Liška  ---
Changed with r8-835-gb7cb2251a32e7af5.

[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

2022-01-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.9.4
   Last reconfirmed||2022-01-07
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Known to work||5.1.0
   Keywords||ice-on-valid-code,
   ||needs-bisection

--- Comment #8 from Andrew Pinski  ---
Seems to have been fixed in GCC 5+. Be interesting to see what revision fixed
this.

[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

2015-01-26 Thread torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594

--- Comment #6 from torvald at gcc dot gnu.org ---
We can keep it open, but my guess is that it would need some volunteer to
actively drive the backporting process. I.e., with a patch and testing.  Given
that TM is experimental, I think backporting fixes for TM has low priority on
most people's todo list.


[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

2015-01-26 Thread torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594

torvald at gcc dot gnu.org changed:

   What|Removed |Added

Version|5.0 |4.9.1

--- Comment #7 from torvald at gcc dot gnu.org ---
Changed version to 4.9.1.


[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

2015-01-26 Thread hammacher at cs dot uni-saarland.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594

Clemens Hammacher hammacher at cs dot uni-saarland.de changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #5 from Clemens Hammacher hammacher at cs dot uni-saarland.de ---
I confirm that it seems to be fixed in SVN trunk. 
Changed version to 4.9.1 without further testing - I don't have the
corresponsing versions on my machine.


[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

2015-01-23 Thread patrick.marlier at gmail dot com
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 libitm/61594] ICE (assertion failure) in trans-mem.c

2015-01-23 Thread torvald at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||torvald at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #3 from torvald at gcc dot gnu.org ---
I can't reproduce this on SVN trunk (r220039), so I'll close this for now.

I didn't spot anything bad when briefly looking at the generated code.


[Bug libitm/61594] ICE (assertion failure) in trans-mem.c

2014-07-03 Thread patrick.marlier at gmail dot com
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

2014-07-03 Thread patrick.marlier at gmail dot com
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.