================
@@ -3205,7 +3180,17 @@ LValue CIRGenFunction::emitConditionalOperatorLValue(
assert((info.lhs || info.rhs) &&
"both operands of glvalue conditional are throw-expressions?");
- return info.lhs ? *info.lhs : *info.rhs;
+
+ // Only one arm produced an lvalue; the other was a throw-expression. The
+ // surviving arm's pointer was materialized inside the ternary's region and
+ // is not visible past the op, so address the result through the ternary's
+ // result value, which the region's cir.yield carries out.
+ LValue &survivingLV = info.lhs ? *info.lhs : *info.rhs;
+ Address survivingAddr = survivingLV.getAddress();
+ Address result(info.result, survivingAddr.getElementType(),
+ survivingAddr.getAlignment());
+ assert(!cir::MissingFeatures::opTBAA());
+ return makeAddrLValue(result, expr->getType(), survivingLV.getBaseInfo());
----------------
kumarak wrote:
@andykaylor, The usage of the `phi` value in the test is the side-effect of
this change, but the change is to fix the verifier error with the test below:
```
int &ref_cond(bool c, int &x) { return c ? x : throw 0; }
```
The previous implementation of one-arm throw returned an LValue whose pointer
was materialized within the ternary's region. When the surviving arm is a local
variable, that pointer is a `cir.alloca`, so it stays visible after the op and
everything works, including the tests. But when the arm has to operate on its
pointers (like loading a reference parameter, cir.get_member through a
pointer), that value is region-local, and any use after the ternary fails
verification.
It works with the Classic codegen pipeline because the CFG is flat, and
returning an LValue does not create the issue. But with CIR, the `cir.ternary`
region boundary breaks the logic, and the only legal way to carry the pointer
out is through yield/result.
Please let me know if it makes it clear. I have added a regression test
covering the scenario.
https://github.com/llvm/llvm-project/pull/210384
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
