* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
@ 2011-02-15 15:36 ` aldyh at gcc dot gnu.org
2011-02-15 15:38 ` aldyh at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aldyh at gcc dot gnu.org @ 2011-02-15 15:36 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
2011-02-15 15:36 ` [Bug c++/47606] " aldyh at gcc dot gnu.org
@ 2011-02-15 15:38 ` aldyh at gcc dot gnu.org
2011-02-15 16:07 ` patrick.marlier at gmail dot com
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aldyh at gcc dot gnu.org @ 2011-02-15 15:38 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
2011-02-15 15:36 ` [Bug c++/47606] " aldyh at gcc dot gnu.org
2011-02-15 15:38 ` aldyh at gcc dot gnu.org
@ 2011-02-15 16:07 ` patrick.marlier at gmail dot com
2011-02-23 19:46 ` aldyh at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: patrick.marlier at gmail dot com @ 2011-02-15 16:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (2 preceding siblings ...)
2011-02-15 16:07 ` patrick.marlier at gmail dot com
@ 2011-02-23 19:46 ` aldyh at gcc dot gnu.org
2011-02-24 19:09 ` aldyh at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aldyh at gcc dot gnu.org @ 2011-02-23 19:46 UTC (permalink / raw)
To: gcc-bugs
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 :(
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (3 preceding siblings ...)
2011-02-23 19:46 ` aldyh at gcc dot gnu.org
@ 2011-02-24 19:09 ` aldyh at gcc dot gnu.org
2011-02-24 19:13 ` aldyh at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aldyh at gcc dot gnu.org @ 2011-02-24 19:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (4 preceding siblings ...)
2011-02-24 19:09 ` aldyh at gcc dot gnu.org
@ 2011-02-24 19:13 ` aldyh at gcc dot gnu.org
2011-03-07 16:18 ` aldyh at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aldyh at gcc dot gnu.org @ 2011-02-24 19:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (5 preceding siblings ...)
2011-02-24 19:13 ` aldyh at gcc dot gnu.org
@ 2011-03-07 16:18 ` aldyh at gcc dot gnu.org
2011-06-17 16:03 ` rth at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: aldyh at gcc dot gnu.org @ 2011-03-07 16:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (6 preceding siblings ...)
2011-03-07 16:18 ` aldyh at gcc dot gnu.org
@ 2011-06-17 16:03 ` rth at gcc dot gnu.org
2011-06-17 16:04 ` rth at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rth at gcc dot gnu.org @ 2011-06-17 16:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (7 preceding siblings ...)
2011-06-17 16:03 ` rth at gcc dot gnu.org
@ 2011-06-17 16:04 ` rth at gcc dot gnu.org
2011-07-12 17:22 ` rth at gcc dot gnu.org
2011-11-02 15:41 ` patrick.marlier at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: rth at gcc dot gnu.org @ 2011-06-17 16:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (8 preceding siblings ...)
2011-06-17 16:04 ` rth at gcc dot gnu.org
@ 2011-07-12 17:22 ` rth at gcc dot gnu.org
2011-11-02 15:41 ` patrick.marlier at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: rth at gcc dot gnu.org @ 2011-07-12 17:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
2011-02-04 11:18 [Bug c++/47606] New: [trans-mem] internal compiler error in expand_block_tm with O2 patrick.marlier at gmail dot com
` (9 preceding siblings ...)
2011-07-12 17:22 ` rth at gcc dot gnu.org
@ 2011-11-02 15:41 ` patrick.marlier at gmail dot com
10 siblings, 0 replies; 12+ messages in thread
From: patrick.marlier at gmail dot com @ 2011-11-02 15:41 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 12+ messages in thread