Skip to content

Conversation

DavidSpickett
Copy link
Collaborator

@DavidSpickett DavidSpickett commented Oct 1, 2025

Fixes #157674

On ARM, the presence of a specific bf16 type in the AST is gated by:

bool ARMTargetInfo::hasBFloat16Type() const {
  // The __bf16 type is generally available so long as we have any fp registers.
  return HasBFloat16 || (FPU && !SoftFloat);
}

And the target we use when evaluating symbols (derived from the program file, I think, haven't found it yet) does not enable any of this.

This means that we fall back to __fp16.

So for parts of the testing we just need to expect __fp16 instead, and others we need to skip because now a class looks like it inherits from itself.

There's a proper fix here somewhere but I don't know what it is yet.

On ARM, the presence of a specific bf16 type in the AST is gated by:
bool ARMTargetInfo::hasBFloat16Type() const {
  // The __bf16 type is generally available so long as we have any fp registers.
  return HasBFloat16 || (FPU && !SoftFloat);
}

And the target we use when evaluating symbols (derived from the program file,
I think, haven't found it yet) does not enable any of this.

This means that we fall back to __fp16.

So for parts of the testing we just need to expect __fp16 instead,
and others we need to skip because now a class looks like it inherits from
itself.

There's a proper fix here somewhere but I don't know what it is yet.
@llvmbot
Copy link
Member

llvmbot commented Oct 1, 2025

@llvm/pr-subscribers-lldb

Author: David Spickett (DavidSpickett)

Changes

Fixes #157674

On ARM, the presence of a specific bf16 type in the AST is gated by:

bool ARMTargetInfo::hasBFloat16Type() const {
  // The __bf16 type is generally available so long as we have any fp registers.
  return HasBFloat16 || (FPU && !SoftFloat);
}

And the target we use when evaluating symbols (derived from the program file, I think, haven't found it yet) does not enable any of this.

This means that we fall back to __fp16.

So for parts of the testing we just need to expect __fp16 instead, and others we need to skip because now a class looks like it inherits from itself.

There's a proper fix here somewhere but I don't know what it is yet.


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

2 Files Affected:

  • (modified) lldb/test/API/lang/cpp/floating-types-specialization/TestCppFloatingTypesSpecialization.py (+18-4)
  • (modified) lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py (+7-2)
diff --git a/lldb/test/API/lang/cpp/floating-types-specialization/TestCppFloatingTypesSpecialization.py b/lldb/test/API/lang/cpp/floating-types-specialization/TestCppFloatingTypesSpecialization.py
index 9564a0bc31809..f4530cd545046 100644
--- a/lldb/test/API/lang/cpp/floating-types-specialization/TestCppFloatingTypesSpecialization.py
+++ b/lldb/test/API/lang/cpp/floating-types-specialization/TestCppFloatingTypesSpecialization.py
@@ -1,4 +1,5 @@
 import lldb
+import lldbsuite.test.lldbplatformutil as lldbplatformutil
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
@@ -11,12 +12,25 @@ def test(self):
             self, "// break here", lldb.SBFileSpec("main.cpp", False)
         )
 
-        self.expect_expr("f0", result_type="Foo<__bf16>")
-        self.expect_expr("f1", result_type="Foo<__fp16>")
+        # On 32-bit Arm, you have to have the bfloat16 extension, or an FPU while
+        # not using the soft float mode. The target we assume has none of that
+        # so instead of __bf16 we get __fp16.
+        is_arm_32_bit = lldbplatformutil.getArchitecture() == "arm"
+
+        self.expect_expr(
+            "f0", result_type=("Foo<__fp16>" if is_arm_32_bit else "Foo<__bf16>")
+        )
+
+        # When __bf16 is actually __fp16, f1 looks like it inherits from itself.
+        # Which clang allows but LLDB fails to evaluate.
+        if not is_arm_32_bit:
+            self.expect_expr("f1", result_type="Foo<__fp16>")
 
         # Test sizeof to ensure while computing layout we don't do
         # infinite recursion.
         v = self.frame().EvaluateExpression("sizeof(f0)")
         self.assertEqual(v.GetValueAsUnsigned() > 0, True)
-        v = self.frame().EvaluateExpression("sizeof(f1)")
-        self.assertEqual(v.GetValueAsUnsigned() > 0, True)
+
+        if not is_arm_32_bit:
+            v = self.frame().EvaluateExpression("sizeof(f1)")
+            self.assertEqual(v.GetValueAsUnsigned() > 0, True)
diff --git a/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py b/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py
index f26d382bf8582..83c057220410a 100644
--- a/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py
+++ b/lldb/test/API/lang/cpp/template-arguments/TestCppTemplateArguments.py
@@ -1,4 +1,5 @@
 import lldb
+import lldbsuite.test.lldbplatformutil as lldbplatformutil
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
@@ -82,8 +83,12 @@ def test(self):
         value = self.expect_expr("temp7", result_type="Foo<__fp16, __fp16>")
         self.assertFalse(value.GetType().GetTemplateArgumentValue(target, 1))
 
-        value = self.expect_expr("temp8", result_type="Foo<__bf16, __bf16>")
-        self.assertFalse(value.GetType().GetTemplateArgumentValue(target, 1))
+        # The target we use when evaluating these expressions for Arm leads to there
+        # not being a __bf16 type in the AST so we fall back to __fp16 and evaluating
+        # this fails.
+        if lldbplatformutil.getArchitecture() != "arm":
+            value = self.expect_expr("temp8", result_type="Foo<__bf16, __bf16>")
+            self.assertFalse(value.GetType().GetTemplateArgumentValue(target, 1))
 
         value = self.expect_expr("temp9", result_type="Bar<double, 1.200000e+00>")
         template_param_value = value.GetType().GetTemplateArgumentValue(target, 1)

@DavidSpickett
Copy link
Collaborator Author

Landing to get the bot green.

@DavidSpickett DavidSpickett merged commit edb80a8 into llvm:main Oct 1, 2025
9 of 11 checks passed
@DavidSpickett DavidSpickett deleted the lldb-arm-bf16 branch October 1, 2025 14:53
mahesh-attarde pushed a commit to mahesh-attarde/llvm-project that referenced this pull request Oct 3, 2025
Fixes llvm#157674

On ARM, the presence of a specific bf16 type in the AST is gated by: 
```
bool ARMTargetInfo::hasBFloat16Type() const {
  // The __bf16 type is generally available so long as we have any fp registers.
  return HasBFloat16 || (FPU && !SoftFloat);
}
```

And the target we use when evaluating symbols (derived from the program
file, I think, haven't found it yet) does not enable any of this.

This means that we fall back to __fp16.

So for parts of the testing we just need to expect __fp16 instead, and
others we need to skip because now a class looks like it inherits from
itself.

There's a proper fix here somewhere but I don't know what it is yet.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants