Skip to content

Conversation

n2h9
Copy link

@n2h9 n2h9 commented Oct 16, 2025

Return correct VTableClass name for Type::ObjCObjectPointer, Type::Pointer as defined in ItaniumCXXABI.cpp

tests

  • added "throw" test for Type::Pointer;
  • didn't add test for Type::ObjCObjectPointer, because it depends on ObjCInterface which triggers error: ClangIR code gen Not Yet Implemented:;

notes

It was mentioned in the issue one type per pr, but as this types suppose to have same vTable class name, I think it should be ok to handle them together, (let me know if not).

Also as there is dependency for Type::ObjCObjectPointer, let me know if it is better to temporally split this cases

  case Type::ObjCObjectPointer:
  case Type::Pointer:

and keep Type::ObjCObjectPointer with cgm.errorNYI


Issue #163601

…e::ObjCObjectPointer, Type::Pointer

Signed-off-by: Nikita B <n2h9z4@gmail.com>
Copy link

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.

n2h9 added 2 commits October 18, 2025 13:15
Signed-off-by: Nikita B <n2h9z4@gmail.com>
@n2h9 n2h9 marked this pull request as ready for review October 18, 2025 11:34
@llvmbot llvmbot added clang Clang issues not falling into any other category ClangIR Anything related to the ClangIR project labels Oct 18, 2025
@llvmbot
Copy link
Member

llvmbot commented Oct 18, 2025

@llvm/pr-subscribers-clangir

@llvm/pr-subscribers-clang

Author: None (n2h9)

Changes

Return correct VTableClass name for Type::ObjCObjectPointer, Type::Pointer as defined in ItaniumCXXABI.cpp

tests

  • added "throw" test for Type::Pointer;
  • didn't add test for Type::ObjCObjectPointer, because it depends on ObjCInterface which triggers error: ClangIR code gen Not Yet Implemented:;

notes

It was mentioned in the issue one type per pr, but as this types suppose to have same vTable class name, I think it should be ok to handle them together, (let me know if not).

Also as there is dependency for Type::ObjCObjectPointer, let me know if it is better to temporally split this cases

  case Type::ObjCObjectPointer:
  case Type::Pointer:

and keep Type::ObjCObjectPointer with cgm.errorNYI


Issue #163601


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

2 Files Affected:

  • (modified) clang/lib/CIR/CodeGen/CIRGenItaniumCXXABI.cpp (+1-2)
  • (modified) clang/test/CIR/CodeGen/throws.cpp (+29)
diff --git a/clang/lib/CIR/CodeGen/CIRGenItaniumCXXABI.cpp b/clang/lib/CIR/CodeGen/CIRGenItaniumCXXABI.cpp
index c184d4a4b1d97..24d0432fb47bb 100644
--- a/clang/lib/CIR/CodeGen/CIRGenItaniumCXXABI.cpp
+++ b/clang/lib/CIR/CodeGen/CIRGenItaniumCXXABI.cpp
@@ -977,8 +977,7 @@ const char *vTableClassNameForType(const CIRGenModule &cgm, const Type *ty) {
 
   case Type::ObjCObjectPointer:
   case Type::Pointer:
-    cgm.errorNYI("VTableClassNameForType: __pointer_type_info");
-    break;
+    return "_ZTVN10__cxxabiv119__pointer_type_infoE";
 
   case Type::MemberPointer:
     cgm.errorNYI("VTableClassNameForType: __pointer_to_member_type_info");
diff --git a/clang/test/CIR/CodeGen/throws.cpp b/clang/test/CIR/CodeGen/throws.cpp
index 53af1efc22cd4..bedb09a2d82ec 100644
--- a/clang/test/CIR/CodeGen/throws.cpp
+++ b/clang/test/CIR/CodeGen/throws.cpp
@@ -244,3 +244,32 @@ void throw_enum_class_expr() {
 // OGCG: store i32 0, ptr %[[EXCEPTION_ADDR]], align 16
 // OGCG: call void @__cxa_throw(ptr %[[EXCEPTION_ADDR]], ptr @_ZTIZ21throw_enum_class_exprvE4Test, ptr null)
 // OGCG: unreachable
+
+void throw_pointer_type() {
+  static int var = 42;
+  int *ptr = &var;
+  throw ptr;
+}
+
+// CIR: %[[PTR_ADDR:.*]] = cir.alloca !cir.ptr<!s32i>, !cir.ptr<!cir.ptr<!s32i>>, ["ptr", init]
+// CIR: %[[VAR_ADDR:.*]] = cir.get_global @_ZZ18throw_pointer_typevE3var : !cir.ptr<!s32i>
+// CIR: cir.store{{.*}} %[[VAR_ADDR]], %[[PTR_ADDR]] : !cir.ptr<!s32i>, !cir.ptr<!cir.ptr<!s32i>>
+// CIR: %[[EXCEPTION_ADDR:.*]] = cir.alloc.exception 8 -> !cir.ptr<!cir.ptr<!s32i>>
+// CIR: %[[TMP_PTR:.*]] = cir.load{{.*}} %[[PTR_ADDR]] : !cir.ptr<!cir.ptr<!s32i>>, !cir.ptr<!s32i>
+// CIR: cir.store{{.*}} %[[TMP_PTR]], %[[EXCEPTION_ADDR]] : !cir.ptr<!s32i>, !cir.ptr<!cir.ptr<!s32i>>
+// CIR: cir.throw %[[EXCEPTION_ADDR]] : !cir.ptr<!cir.ptr<!s32i>>, @_ZTIPi
+// CIR: cir.unreachable
+
+// LLVM: %[[PTR_ADDR:.*]] = alloca ptr,{{.*}} align 8
+// LLVM: store ptr @_ZZ18throw_pointer_typevE3var, ptr %[[PTR_ADDR]], align 8
+// LLVM: %[[EXCEPTION_ADDR:.*]] = call ptr @__cxa_allocate_exception(i64 8)
+// LLVM: %[[TMP_PTR:.*]] = load ptr, ptr %[[PTR_ADDR]], align 8
+// LLVM: store ptr %[[TMP_PTR]], ptr %[[EXCEPTION_ADDR]], align 16
+// LLVM: call void @__cxa_throw(ptr %[[EXCEPTION_ADDR]], ptr @_ZTIPi, ptr null)
+
+// OGCG: %[[PTR_ADDR:.*]] = alloca ptr, align 8
+// OGCG: store ptr @_ZZ18throw_pointer_typevE3var, ptr %[[PTR_ADDR]], align 8
+// OGCG: %[[EXCEPTION_ADDR:.*]] = call ptr @__cxa_allocate_exception(i64 8)
+// OGCG: %[[TMP_PTR:.*]] = load ptr, ptr %[[PTR_ADDR]], align 8
+// OGCG: store ptr %[[TMP_PTR]], ptr %[[EXCEPTION_ADDR]], align 16
+// OGCG: call void @__cxa_throw(ptr %[[EXCEPTION_ADDR]], ptr @_ZTIPi, ptr null)

@n2h9
Copy link
Author

n2h9 commented Oct 19, 2025

I have just walked through this code in debugger, and looks like when we throw pointer to int, we do not reach this case

  case Type::ObjCObjectPointer:
  case Type::Pointer:
    return "_ZTVN10__cxxabiv119__pointer_type_infoE";

we reach it if we throw pointer to object. But in that case I receive error: ClangIR code gen Not Yet Implemented: buildTypeInfo: Pointer let me check how to handle this 😊

@n2h9 n2h9 marked this pull request as draft October 19, 2025 12:27
// OGCG: call void @__cxa_throw(ptr %[[EXCEPTION_ADDR]], ptr @_ZTIZ21throw_enum_class_exprvE4Test, ptr null)
// OGCG: unreachable

void throw_pointer_type() {
Copy link
Author

Choose a reason for hiding this comment

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

This test must be upated to throw pointer to object, if we throw pointer to int it does not go in case Type::Pointer:

@n2h9
Copy link
Author

n2h9 commented Oct 20, 2025

I have just walked through this code in debugger, and looks like when we throw pointer to int, we do not reach this case

  case Type::ObjCObjectPointer:
  case Type::Pointer:
    return "_ZTVN10__cxxabiv119__pointer_type_infoE";

we reach it if we throw pointer to object. But in that case I receive error: ClangIR code gen Not Yet Implemented: buildTypeInfo: Pointer let me check how to handle this 😊

I have just walked through this code in debugger, and looks like when we throw pointer to int, we do not reach this case

  case Type::ObjCObjectPointer:
  case Type::Pointer:
    return "_ZTVN10__cxxabiv119__pointer_type_infoE";

we reach it if we throw pointer to object. But in that case I receive error: ClangIR code gen Not Yet Implemented: buildTypeInfo: Pointer let me check how to handle this 😊

Skip VTableClassNameForType function update for now for:

  • Type::ObjCObjectPointer
  • Type::Pointer

Because this types handling is not implemented yet, as per this comment #163601 (comment)

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

Labels

clang Clang issues not falling into any other category ClangIR Anything related to the ClangIR project

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants