https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101426
Bug ID: 101426 Summary: Wrong code redirecting IPA thunk parms to tail-call Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Target Milestone: --- Created attachment 51135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51135&action=edit Testcase Building the attached testcase with: cc1plus -fpreprocessed t.cc -quiet -m64 -mzarch -O2 Produces wrong code with GCC commits up to g:9725df0233b A specialized clone of AShrOp::build without the first parameter is created. The calls in the foo* functions to the clone have to shift the function parameters one hard reg down to fit the signature of the clone: void r::NSPACE::foo1 (struct OpBuilder & D.2900, struct OperationState & state, struct ValueRange operands, struct ArrayRef attributes) { <bb 2> [local count: 1073741824]: r::NSPACE::AShrOp::build.constprop (state_3(D), operands, attributes); [tail call] return; } The generated code overwrites the 2. and the 3. parameter with the 4. of the caller: lgr %r2,%r3 lgr %r4,%r5 lgr %r3,%r5 jg _ZN1r6NSPACE6AShrOp5buildERNS_9OpBuilderERNS_14OperationStateENS_10ValueRangeEN6nspace8ArrayRefISt4pairINS_10IdentifierENS_9AttributeEEEE.constprop.0 The problem does not occur on head and 10.3 after this commit g:defafb78cbc With this the parameters are always copied. The fix was done for PR90448 to fix an ICE triggered when building and address operand based on the DECL_RTL of the parameter which wasn't addressable at that point. I think the situation is a bit different here. The code wires up the incoming hardregs with the callee parms without considering that the resulting moves might affect each other.