Hello, First, I apologize to my question is not clear. And thanks for you still give me help. I take your advice and finally worked with unlink_stmt_vdef to solve the error. I do really appreciate you. Lee Jeff Law <law@xxxxxxxxxx> 於 2019年6月4日 週二 上午3:54寫道： > On 6/3/19 12:18 PM, Marc Glisse wrote: > > On Tue, 4 Jun 2019, 李宗霖 wrote: > > > >> I use gsi_remove to remove some call statement. > >> Then it comes out some error message after the last basic block. > >> But I didn't use the function(ex. like dominated_by_p, > >> get_continuation_for_phi, etc) in these error message. > >> After that, I add bitmap_set_bit to fix, but it still the same. > > > > The description is super vague... If you look at other places in the > > compiler that use gsi_remove, there are often some other necessary > > cleanups next to it, typically unlink_stmt_vdef or release_defs, but > > there can be others depending on the type of statement, the pass, etc. > > The issue may not manifest immediately but only the next time something > > tries to use a datastructure that wasn't updated. > > It isn't clear what bitmap_set_bit has to do with anything, without > > context. > The release_defs and such shouldn't be fatal like this -- you end up > leaking SSA_NAMEs, but that's not the end of the world. > > The particular error in this case indicates that removal of the call is > somehow changing the shape of the control flow graph. This can > potentially clobber the dominance graph as well. > > BUt yes, the report is too vague to really diagnose what's going on. > > jeff > >
