This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Get rid of LOOP_EXPRs


Hello,

>  >> Can you put the bsi_next_in_bb change into a separate patch
>  >
>  >yes I could; but given that it is just that one line, it would be
>  >perhaps easier if you just imagined I did it :-)
> In general, it's best to send unrelated patches as separate messages.  However,
> since I've already got a test running with just this one patch installed,
> I'll go ahead and take responsibility to break it out.

sorry for this; I was in an extremely lazy mood yesterday :-(

>  >> The reason I ask is I'm not sure your change is sufficient to make the
>  >> compiler safe when treating BIND_EXPRs as starting/ending blocks.  Consider
>  >> what happens when we merge blocks and call replace_stmt with TP2 being
>  >> a COMPOUND_EXPR.  That's going to create new BIND_EXPRs.  Those BIND_EXPRs
>  >> can't create new blocks (because the block merging code assumes that one
>  >> of the two blocks is going to go away).
>  >
>  >yes, this will have to be handled; given that everything seems to work
>  >(as BIND_EXPRs usually are not seen), could this be solved in a followup
>  >patch?
> I'd prefer not to handle it as a follow-up since failure to handle these
> cases can result in aborts and possibly even incorrect code.  That's
> from firsthand knowledge of poking at BIND_EXPR removal briefly.

OK, I will try to replace this missing piece + I will write a code to
check that the BIND_EXPRs don't occur in the middle of basic blocks
into tree_verify_flow_info; thus it should get tested properly.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]