Hello, I'm on holiday, but I'm back home tomorrow.
Imho the active-insn "idiom" is the best solution for the moment. I will fix this mess properly asap, probably next week. Ciao! Steven On 5/3/13, Steve Ellcey <sell...@imgtec.com> wrote: > On Tue, 2013-04-30 at 15:05 +0100, Richard Sandiford wrote: >> Richard Sandiford <rdsandif...@googlemail.com> writes: >> > Steven Bosscher <stevenb....@gmail.com> writes: >> >> I dont like this at all. At the very least, if we go this way, >> >> then all places where next_active_insn is used should be updated. >> >> Otherwise this is just confusion proliferation. >> > >> > You mean all places where next_active_insn is used to get the jump >> > table? >> > That would be fine with me, but as author of the original change, >> > I'm going to ask you to do that if you feel strongly about it :-) >> > Otherwise Steve's patch seems fine to me. >> > >> >> Before my patch most >> >> ports used the "active" variants and I specifically did non fix the >> >> "real" variants. It is marked fixme for a reason: The JUMP_TABLE_DATA >> >> should always follow immediately after the label. Copying the fixme is >> >> a step in the wrong direction. Please do not commit this patch! >> > >> > But you didn't respond to my main point. It always used to be the >> > case that all "active" insns were also "real". I.e. "real" was a >> > _more_ restrictive condition than "active". >> >> Gah, I really wish proof reads before hitting "send" were as effective >> as those after. Obviously that should read: "active" was a _more_ >> restrictive condition than "real". >> >> Richard > > Steven, > > Do you have any comment on Richard's question? I am basically stuck > between the two of you with no way to fix my problem at this point > unless you allow the generic fix or Richard allows the MIPS specific > fix. > > Steve Ellcey > sell...@imgtec.com > > > > >
