https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69155
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > I think we have a dup/related bug where we run into the issue that > tree-complex.c > wrecks SSA form during its rewrite. That is indeed what happens, but what solution do you see other than avoiding all the simplifications/optimizations that follow ssa edges? We have: <bb 4>: # a_22 = PHI <a_11(4), a_18(3)> # b_23 = PHI <b_10(4), b_17(3)> # a$real_28 = PHI <a$real_30(4), a$real_24(3)> # a$imag_29 = PHI <a$imag_31(4), a$imag_25(3)> # b$real_32 = PHI <b$real_34(4), b$real_26(3)> # b$imag_33 = PHI <b$imag_35(4), b$imag_27(3)> _9 = __complex__ (1.0e+0, 0.0) / a_22; b_10 = b_23 - _9; a_11 = a_22 + __complex__ (1.0e+0, 0.0); _8 = REALPART_EXPR <a_11>; if (_8 < 1.0e+1) goto <bb 4>; else goto <bb 5>; While we could avoid the crash on lowering the division by handling it last, e.g. the addition has a loop of dependencies, so either we create a PHI first, but then don't have definitions for its arguments, or we lower the + first, but then we don't have definition for the PHI. We can't create all the statements in a transaction together. Do you suggest we set some temporary SSA_NAME_DEF_STMTs for the SSA_NAMEs we create and we don't have a real definition yet (say GIMPLE_NOP)? Wouldn't some simplification attempt to optimize it as uninitialized? Or stop using gimple_build* and revert to constructing it using builders that don't actually fold anything or try to optimize anything, and when we have everything fold all newly added statements?
