kikairoya wrote:
> Thanks! I took the liberty to further reword it a bit more, to clarify the
> scope - let me know if you disagree with the wording.
Thank you for your follow-up. I really appreciate it.
https://github.com/llvm/llvm-project/pull/150938
https://github.com/kikairoya edited
https://github.com/llvm/llvm-project/pull/150938
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/kikairoya updated
https://github.com/llvm/llvm-project/pull/150938
>From 4cc5f4e94f7e87026418c2965e2e0a699e431cf8 Mon Sep 17 00:00:00 2001
From: kikairoya
Date: Mon, 28 Jul 2025 22:02:55 +0900
Subject: [PATCH 1/2] [clang][DebugInfo] Disable VTable debug info (#130255) on
COF
kikairoya wrote:
I must fix `debug-info-class.cpp` and `ExtDebugInfo.cpp`. Former is obvious,
but latter uses `%itanium_abi_triple` then output relies on default target. Is
it okay to add `UNSUPPORTED: target={{.*(windows|mingw|cyg).*}}`, or should I
separate by target?
https://github.com/llv
https://github.com/kikairoya created
https://github.com/llvm/llvm-project/pull/150938
On COFF platform, d1b0cbff806b50d399826e79b9a53e4726c21302 generates a debug
info linked with VTable even if that is dllimport-ed. That causes an access
violation while performing runtime pseudo-relocation if
https://github.com/kikairoya updated
https://github.com/llvm/llvm-project/pull/150938
>From 4cc5f4e94f7e87026418c2965e2e0a699e431cf8 Mon Sep 17 00:00:00 2001
From: kikairoya
Date: Mon, 28 Jul 2025 22:02:55 +0900
Subject: [PATCH 1/3] [clang][DebugInfo] Disable VTable debug info (#130255) on
COF
kikairoya wrote:
> Former is obvious, but latter uses `%itanium_abi_triple` then output relies
> on default target. Is it okay to add `UNSUPPORTED:
> target={{.*(windows|mingw|cyg).*}}`, or should I separate by target?
I've diverged with '%if' directive.
https://github.com/llvm/llvm-project/p
kikairoya wrote:
> Minor nit, we could adjust the commit message (PR description), saying "even
> if that may be dllimported", instead of "is dllimported". If it has an
> explicit dllimport, iirc this issue doesn't hit at all - it's the "maybe
> dllimported" case which is problematic here.
Up
@@ -222,3 +222,8 @@ void foo() {
// CHECK: !DICompositeType(tag: DW_TAG_class_type, name: "A",
// CHECK-SAME: DIFlagFwdDecl
+
+// There is a full definition of the type available in the module.
+// CHECKCOFF: !DICompositeType(tag: DW_TAG_structure_type, name: "Virt
