public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/57055] New: Incorrect CFG after transactional memory passes
@ 2013-04-24 12:22 enkovich.gnu at gmail dot com
2013-04-24 13:15 ` [Bug middle-end/57055] " jakub at gcc dot gnu.org
2013-04-25 8:17 ` rguenth at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: enkovich.gnu at gmail dot com @ 2013-04-24 12:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57055
Bug #: 57055
Summary: Incorrect CFG after transactional memory passes
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: enkovich.gnu@gmail.com
Transactional passes do not set cfun->calls_setjmp to true and do not fix CFG
accordingly after adding __builtin__ITM_beginTransaction call having
ECF_RETURNS_TWICE flag set.
It leads to inconsistency which may be revealed with special calls flags
recomputation.
If I add DCE pass after transactional memory then flags are recomputed and CFG
check fails because of call statements in the middle of basic block. Thus DCE
pass after transactional memory causes ~250 new fails in 'make check'.
Tried on 'gcc version 4.9.0 20130422 (experimental) (GCC)'
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/57055] Incorrect CFG after transactional memory passes
2013-04-24 12:22 [Bug middle-end/57055] New: Incorrect CFG after transactional memory passes enkovich.gnu at gmail dot com
@ 2013-04-24 13:15 ` jakub at gcc dot gnu.org
2013-04-25 8:17 ` rguenth at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: jakub at gcc dot gnu.org @ 2013-04-24 13:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57055
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-24 13:15:46 UTC ---
I think the TM code was taking care of edges so far, so either this TM
shouldn't be handled as ECF_RETURNS_TWICE for the purposes of the ab edge
creation code added recently by Richard, or we should handle it like any other
returns_twice.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/57055] Incorrect CFG after transactional memory passes
2013-04-24 12:22 [Bug middle-end/57055] New: Incorrect CFG after transactional memory passes enkovich.gnu at gmail dot com
2013-04-24 13:15 ` [Bug middle-end/57055] " jakub at gcc dot gnu.org
@ 2013-04-25 8:17 ` rguenth at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-04-25 8:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57055
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-04-25
Blocks| |56982
Ever Confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-25 08:17:07 UTC ---
I think we should handle it like any other returns-twice, that is, TM should
split the block properly (and either call notice_special_calls or set
->calls_setjmp). TM can still handle edge creation itself because it knows
where abnormal transfer can originate from.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-04-25 8:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-24 12:22 [Bug middle-end/57055] New: Incorrect CFG after transactional memory passes enkovich.gnu at gmail dot com
2013-04-24 13:15 ` [Bug middle-end/57055] " jakub at gcc dot gnu.org
2013-04-25 8:17 ` rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).