https://bugs.kde.org/show_bug.cgi?id=417281
--- Comment #4 from Julian Seward <jsew...@acm.org> --- I studied this more today. One theory I had was that the insn selector was generating wrong code for converting a value in the lowest bit of a register into a condition code (function s390_isel_cc(), case "/* Variable: values are 1 or 0 */"), due to testing the whole register without first masking off all but the least significant bit. However, I added code to first copy the register, do the masking, and only then the test. This had no effect :-( I then looked in detail at the front end actions (the &&-recovery) for the basic block(s) where the failure happens. This all seems to be correct to me. Plus, all that front end logic is target-independent, and if it was broken I would have expected it to have failed on some other target by now. I looked some s390 insn selector bits and pieces relating to converting integer values to/from condition codes, but didn't see any error there. So I'm still not sure what is going on. Given that the front end stuff works OK on other targets, it might be that this is an s390 insn selector bug which has was always there but has only shown up because the &&-recovery transformation causes the back end to be given a wider variety of IR. Even that sounds pretty unlikely, though. As a next step I am inclined to add printf lines for all cases (rules) in the insn selector. Then run the test case with and without &&-recovery enabled, so as to find the sets of rules used in both cases, and diff them, to see what is only used when &&-recovery is enabled. Then look more closely at those cases. Right now I cannot think of anything else to do. I will try to find time to do that in the next two weeks or so. -- You are receiving this mail because: You are watching all bug changes.
