================
@@ -9125,9 +9126,25 @@ bool
LValueExprEvaluator::VisitCompoundLiteralExpr(const CompoundLiteralExpr *E) {
assert((!Info.getLangOpts().CPlusPlus || E->isFileScope()) &&
"lvalue compound literal in c++?");
- // Defer visiting the literal until the lvalue-to-rvalue conversion. We can
- // only see this when folding in C, so there's no standard to follow here.
- return Success(E);
+ APValue *Lit;
+ // If CompountLiteral has static storage, its value can be used outside
+ // this expression. So evaluate it once and store it in ASTContext.
+ if (E->hasStaticStorage()) {
+ Lit = E->getOrCreateStaticValue(Info.Ctx);
+ Result.set(E);
+ // Reset any previously evaluated state, otherwise evaluation below might
+ // fail.
+ // FIXME: Should we just re-use the previously evaluated value instead?
+ *Lit = APValue();
----------------
kadircet wrote:
sorry for the late response here, it took me a while to wrap my head around it
and then I got interrupted :(
> Roughly, the issue is that, if you constant-evaluate the expression in
> isolation, you get a different result from what you'd get evaluating the
> whole expression. So we can't redo the evaluation in ConstantFold mode: if
> you do, you'll corrupt the precomputed value
I am not sure if this applies to CLEs and even if it does I don't think this
patch is making it worse:
- CLEs can only have constant expressions as initializers, as you also
highlighted above. Hence (i think) evaluating them multiple times or evaluating
sub-parts of them shouldn't matter.
- As things stand clang is already evaluating CLEs from scratch every time it
needs to (so if there's a problem here, it already exists).
> I think compound literals run into similar issues if you allow ConstantFold
> mode to overwrite the evaluated value.
Sorry if I am being dense, but there's a good chance I didn't fully understand
your point. So if you think what I said above doesn't make sense, I'd really
appreciate if you can provide a code snippet that demonstrates such a case?
https://github.com/llvm/llvm-project/pull/137163
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
