[[gnu::weak]] disables constant evaluation of constexpr variables in C++14

[Kirito-89]

Clang's constant evaluator would unconditionally reject the initializer of any [[gnu::weak]] variable. This was intended to prevent unsafe constant folding but also incorrectly blocked valid constant evaluation in C++14 (e.g., static constexpr initialization).

This patch refines the logic to only apply the check when the evaluation mode is not EvaluationMode::ConstantExpression. This fixes the bug by allowing required constexpr evaluation to proceed while still preventing unsafe folding in other contexts.

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Adamya Verma (Kirito-89)

Changes

Clang's constant evaluator would unconditionally reject the initializer of any [[gnu::weak]] variable. This was intended to prevent unsafe constant folding but also incorrectly blocked valid constant evaluation in C++14 (e.g., static constexpr initialization).

This patch refines the logic to only apply the check when the evaluation mode is not EvaluationMode::ConstantExpression. This fixes the bug by allowing required constexpr evaluation to proceed while still preventing unsafe folding in other contexts.

---

Full diff: https://github.com/llvm/llvm-project/pull/166852.diff

1 Files Affected:

• (modified) clang/lib/AST/ExprConstant.cpp (+1-1)

diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 97eeba8b9d6cc..cb3a359a6df95 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -3611,7 +3611,7 @@ static bool evaluateVarDeclInit(EvalInfo &Info, const Expr *E,
 
   // Never use the initializer of a weak variable, not even for constant
   // folding. We can't be sure that this is the definition that will be used.
-  if (VD->isWeak()) {
+  if (VD->isWeak()&& (Info.EvalMode != EvaluationMode::ConstantExpression)) {
     Info.FFDiag(E, diag::note_constexpr_var_init_weak) << VD;
     NoteLValueLocation(Info, Base);
     return false;

[erichkeane]

First, this absolutely needs tests.

Second, this needs to also update the experimental 'bitcode' interpreter @tbaederr has been working on. So we need to make sure the examples/tests/etc are added and work in that as well.

[Kirito-89]

Thanks for this feedback. I'll get started on adding a lit test to clang/test/ to make sure the fix is covered. You're right, I completely missed the experimental interpreter. I'm not familiar with that part of the codebase, could you point me to the files I need to patch for that? Please let me know if there's anything else I've missed, and I'll get all the changes bundled up in the next update.

[erichkeane]

Thanks for this feedback. I'll get started on adding a lit test to clang/test/ to make sure the fix is covered. You're right, I completely missed the experimental interpreter. I'm not familiar with that part of the codebase, could you point me to the files I need to patch for that? Please let me know if there's anything else I've missed, and I'll get all the changes bundled up in the next update.

@tbaederr is the best one to help with the interpreter, I actually dont' really have any experience with it.

[github-actions]

⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️

You can test this locally with the following command:

git-clang-format --diff origin/main HEAD --extensions cpp -- clang/lib/AST/ExprConstant.cpp --diff_from_common_commit

⚠️
The reproduction instructions above might return results for more than one PR
in a stack if you are using a stacked PR workflow. You can limit the results by
changing origin/main to the base branch/commit you want to compare against.
⚠️

View the diff from clang-format here.

diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 7e88e4fae..ea6ee60d3 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -3611,7 +3611,7 @@ static bool evaluateVarDeclInit(EvalInfo &Info, const Expr *E,
 
   // Never use the initializer of a weak variable, not even for constant
   // folding. We can't be sure that this is the definition that will be used.
-  if (VD->isWeak()&& (Info.EvalMode != EvaluationMode::ConstantExpression)) {
+  if (VD->isWeak() && (Info.EvalMode != EvaluationMode::ConstantExpression)) {
     Info.FFDiag(E, diag::note_constexpr_var_init_weak) << VD;
     NoteLValueLocation(Info, Base);
     return false;

[shafik]

So this will also need a release note in clang/docs/ReleaseNotes.rst.

The summary should at least try to outline the difference between safe and unsafe folding. This is important because when evaluating the tests we need to be able to understand if they are covering all the cases outlined.

It would also be nice to understand the motivation for this change, is there some codebase that is hitting this issue?

[shafik]

This comment seems like it need to updated to explain which cases we are now allowing and why they are ok.

[tbaederr]

I have no idea idea if this patch is even correct or not and what kind of "valid" evaluation rejection of gnu::weak variables prevents.
That being said, the same diagnostic is emitted in Interp.cpp in CheckWeak().
However, InterpState currently has no notion of "evaluation mode". That requires some refactoring to State/InterpState/EvalInfo that I've not done yet. If this turns out to be required for this to work, I'll get on it ASAP.