Skip to content

[NFC] Fix evaluation order dependency in call arguments #141366

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

michael-jabbour-sonarsource
Copy link
Contributor

@michael-jabbour-sonarsource michael-jabbour-sonarsource commented May 24, 2025

The code in ARMAsmParser::parseDirectiveReq passes both parseRegister(Reg, SRegLoc, ERegLoc) and SRegLoc as arguments to check(). Since function arguments are indeterminately sequenced per C++17 [expr.call]/5, a compiler can evaluate SRegLoc before parseRegister() executes. This means check() receives a null location instead of the actual parsed source location for error reporting.

The fix separates the calls to establish explicit sequencing, ensuring check() receives the correct source location.

This issue was detected by the CFamily analyzer for SonarQube. I'm happy to provide any additional information or clarification as needed.

The code assumes parseRegister() executes before the standalone SRegLoc
argument to check(). Since function arguments are indeterminately sequenced
per C++17 [expr.call]/5, check() may receive a null location instead of
the actual parsed source location.

Detected by the CFamily analyzer for SonarQube.
https://docs.sonarsource.com/sonarqube-cloud/advanced-setup/languages/c-family/overview/
@llvmbot
Copy link
Member

llvmbot commented May 24, 2025

@llvm/pr-subscribers-backend-arm

Author: Michael Jabbour (michael-jabbour-sonarsource)

Changes

The code in ARMAsmParser::parseDirectiveReq passes both parseRegister(Reg, SRegLoc, ERegLoc) and SRegLoc as arguments to check(). Since function arguments are indeterminately sequenced per C++17 [expr.call]/5, a compiler can evaluate SRegLoc before parseRegister() executes. This means check() receives a null location instead of the actual parsed source location for error reporting.

The fix separates the calls to establish explicit sequencing, ensuring check() receives the correct source location.

This issue was detected by the CFamily analyzer for SonarQube. I'm happy to provide any additional information or clarification as needed.


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

1 Files Affected:

  • (modified) llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp (+2-3)
diff --git a/llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp b/llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
index 85b107c6085d3..ee3dc7d8a3618 100644
--- a/llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
+++ b/llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
@@ -11788,9 +11788,8 @@ bool ARMAsmParser::parseDirectiveReq(StringRef Name, SMLoc L) {
   Parser.Lex(); // Eat the '.req' token.
   MCRegister Reg;
   SMLoc SRegLoc, ERegLoc;
-  if (check(parseRegister(Reg, SRegLoc, ERegLoc), SRegLoc,
-            "register name expected") ||
-      parseEOL())
+  const bool parseResult = parseRegister(Reg, SRegLoc, ERegLoc);
+  if (check(parseResult, SRegLoc, "register name expected") || parseEOL())
     return true;
 
   if (RegisterReqs.insert(std::make_pair(Name, Reg)).first->second != Reg)

Copy link
Collaborator

@davemgreen davemgreen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants