This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/79411] [5/6/7 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 07 Feb 2017 19:40:20 +0000
- Subject: [Bug c/79411] [5/6/7 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)
- Auto-submitted: auto-generated
- References: <bug-79411-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79411
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is just a single SSA_NAME_OCCURS_IN_ABNORMAL_PHI check in
tree-ssa-reassoc.c in the range handling code, I'd say that is significantly
less than what really is needed. Unless we want to add code to be extremely
careful about (ab) SSA_NAMEs, I'd say we just shouldn't try to reassociate
anything involving those. To be precise, it would be ok if say we have:
_2 = d_1(ab) + 1;
...
_5 = _2 + 1;
to turn that into
_30 = d_1(ab);
...
_5 = _30 + 2;
and similar, but the (ab) uses would need to stay at the points they were used
in, I guess that would be a lot of work though (and still we shouldn't look
through (ab) SSA_NAMEs e.g. when linearizing trees etc.
So perhaps it will be much easier to just punt if (ab) appears on lhs or
rhs{1,2}, and don't look through in linearization if there are (ab) operands in
those (so that ops array stays (ab) free. Richard, what do you think about
that?