On 04/02/2018 10:15 AM, co...@sdf.org wrote: > It turns out (all from krister, I am still totally lost) that it is not > failing for this specific reason in this case. > > Rather, the attached patch from krister fixes it, saying that gcc > wants to change the label and then doesn't recognise the new insn > thinking the memory_operand predicate is not satisfied. > The new predicate is from rs6000. > > In retrospect the most important thing to provide was the 4 line shell > script to reproduce the problem, I felt uneasy sharing that because it > is with netbsd's copy of GCC (which I know how to cross-build). > > For the purpose of changing it to support a reversed pc/label_ref, I can > probably cargo-cult make it look like branch and make the square peg fit > in a round hole by a lot experimenting, but I don't understand the code > I have to be changing to do that. > > There is this construct in the code that I don't understand why I want > to do anything like it, even if I can parse what the individual parts of > it mean: > > (set (zero_extract:SI (match_operand:QI 3 "memory_operand" "+0") > (const_int 1) > (match_dup 1)) > (const_int 1))])] > Again, you're almost certainly just papering over hte problem. There's no reason I'm aware of for a zero_extract insn to be restricted to volatile memory operands. All you're doing is making the pattern not match very often which happens to avoid the bug.
I think you need to go back to my earlier reply and read it carefully. In particular, you need an insn where the label_ref and pc are swapped. Jeff
