https://github.com/nga888 closed https://github.com/llvm/llvm-project/pull/94664
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/94664
>From d230adc33f362f5da64ad46da0ac6a969fd4582d Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Fri, 31 May 2024 17:17:18 +0100
Subject: [PATCH] [clang] Fix loss of `dllexport` for exported template
specialization
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/94664
>From 05175ee44ce0b796b641beb34b18d7974c8355d2 Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Fri, 31 May 2024 17:17:18 +0100
Subject: [PATCH 1/2] [clang] Fix loss of `dllexport` for exported template
specializat
nga888 wrote:
> > I did briefly think about this, but does this change really apply to
> > `GetOrCreateLLVMGlobal`? Is there any test case to exercise it? Perhaps it
> > would be better to leave `GetOrCreateLLVMGlobal` as is?
>
> I think we should look at it the other way around: unless there'
nga888 wrote:
> It would be nice to keep `GetOrCreateLLVMGlobal` and
> `GetOrCreateLLVMFunction` in sync. Would it be possible to extract the
> "Handle dropped DLL attributes" logic into a small utility function that
> could be called from both?
I did briefly think about this, but does this c
https://github.com/nga888 closed https://github.com/llvm/llvm-project/pull/93302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
nga888 wrote:
Closing this PR in favour of PR #94664.
https://github.com/llvm/llvm-project/pull/93302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nga888 created
https://github.com/llvm/llvm-project/pull/94664
When dropping DLL attributes, ensure that the most recent declaration is being
checked.
>From 05175ee44ce0b796b641beb34b18d7974c8355d2 Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Fri, 31 May 2024 17:17:18 +01
nga888 wrote:
> > shouldn't there be a test case added for the dropping of dllexport?
>
> I can't think of a test case that would hit it.
Just for clarification, you want to pursue the `getMostRecentDecl()` approach
but keep the code for the dropping of `dllexport` even though there appears to
nga888 wrote:
@zmodem, forgot to ask, and not directly linked to this patch as such, but
shouldn't there be a test case added for the dropping of `dllexport`?
https://github.com/llvm/llvm-project/pull/93302
___
cfe-commits mailing list
cfe-commits@lis
nga888 wrote:
> > However, this fix also causes a dllimport test to fail too, so perhaps that
> > was the "failure" that I encountered, I just don't remember.
>
> Was this about `@_ZdlPv` in `clang/test/CodeGenCXX/dllimport.cpp`? Using
> `getMostRecentDecl()` makes that dllimport, and I think
nga888 wrote:
Ok, I have confirmed that the `getMostRecentDecl()` fix does indeed work on the
`main` branch. When I started debugging this issue sometime ago, I was working
with a downstream branch based off `17.x` using the source file from UE 5.4. I
remember trying the use of `getMostRecentD
nga888 wrote:
> I think the "surprise" is that the latter call to `GetOrCreateLLVMFunction`
> is using an earlier `FunctionDecl`. Because of that, I'm thinking maybe the
> fix is to call `getMostRecentDecl` on it, something like:
Thanks for your time and the update. Yes, this is what I also di
nga888 wrote:
> Well, you're exporting a specialization. How is it going to get imported?
The "importing" side is just:
```
struct s {
template static bool f();
};
bool use_f() { return s::f(); }
```
This test case was derived from code that is part of UnrealEngine 5.4 which
builds fine with
nga888 wrote:
> Here, `dllimport` gets dropped from `s::f()` for the same reason as in
> your test: the AST node which the call in `template_using_f()` refers to is
> missing the attribute. (Godbolt: https://godbolt.org/z/nnfET4r13)
I think the difference in this case, is that this behaviour i
nga888 wrote:
> I'm not sure this is the right place for the fix though. Note that even
> though my patch added handling for dropping dllexport, we still do export `f`
> in this case:
>
> ```
> __declspec(dllexport) int f(int x);
> int user(int x) {
> return f(x);
> }
> int f(int x) { return
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/93302
>From 0cfd700e604e5ec68856dfa7daca378e71795fb2 Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Mon, 20 May 2024 18:26:32 +0100
Subject: [PATCH 1/3] [clang] Fix loss of `dllexport` for exported template
specializat
@@ -4849,9 +4852,12 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef
MangledName, llvm::Type *Ty,
Entry->setLinkage(llvm::Function::ExternalLinkage);
}
-// Handle dropped DLL attributes.
-if (D && !D->hasAttr() && !D->hasAttr() &&
-!shouldMapVisib
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/93302
>From 0cfd700e604e5ec68856dfa7daca378e71795fb2 Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Mon, 20 May 2024 18:26:32 +0100
Subject: [PATCH 1/2] [clang] Fix loss of `dllexport` for exported template
specializat
@@ -4849,9 +4852,12 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef
MangledName, llvm::Type *Ty,
Entry->setLinkage(llvm::Function::ExternalLinkage);
}
-// Handle dropped DLL attributes.
-if (D && !D->hasAttr() && !D->hasAttr() &&
-!shouldMapVisib
nga888 wrote:
> Does the test exercise both modified paths? I'm guessing it only exercises
> GetOrCreateLLVMFunction, but I'm not a codegen expert.
Only 1 path is "exercised" but I believe neither path of the removed code was
exercised previously and no other tests are affected by the code rem
@@ -4849,9 +4852,12 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef
MangledName, llvm::Type *Ty,
Entry->setLinkage(llvm::Function::ExternalLinkage);
}
-// Handle dropped DLL attributes.
-if (D && !D->hasAttr() && !D->hasAttr() &&
-!shouldMapVisib
https://github.com/nga888 created
https://github.com/llvm/llvm-project/pull/93302
In commit 0a20f541, "Better codegen support for DLL attributes being dropped
after the first declaration (PR20792)", code was added to enable "dropping" of
DLL attributes. The specific issue and example given was
https://github.com/nga888 closed https://github.com/llvm/llvm-project/pull/92579
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/92579
>From 09fbe6bf163680105c42d4ecbb502ea6519e8b7b Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Mon, 22 Apr 2024 19:29:01 +0100
Subject: [PATCH] [clang] Fix PS "selective" DLL import/export of vtable &
typeinfo
Pr
@@ -1793,6 +1793,37 @@ void ItaniumCXXABI::EmitDestructorCall(CodeGenFunction
&CGF,
ThisTy, VTT, VTTTy, nullptr);
}
+// Check if any non-inline method has the specified attribute.
+template
+static bool CXXRecordNonInlineHasAttr(const CXXRecordDec
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/92579
>From d0b7fd1062c106f01da7d536185e1702bc09bd09 Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Mon, 22 Apr 2024 19:29:01 +0100
Subject: [PATCH 1/3] [clang] Fix PS "selective" DLL import/export of vtable &
typeinfo
@@ -1793,6 +1793,37 @@ void ItaniumCXXABI::EmitDestructorCall(CodeGenFunction
&CGF,
ThisTy, VTT, VTTTy, nullptr);
}
+// Check if any non-inline method has the specified attribute.
+template
+static bool CXXRecordNonInlineHasAttr(const CXXRecordDec
@@ -1793,6 +1793,37 @@ void ItaniumCXXABI::EmitDestructorCall(CodeGenFunction
&CGF,
ThisTy, VTT, VTTTy, nullptr);
}
+// Check if any non-inline method has the specified attribute.
+template
+static bool CXXRecordNonInlineHasAttr(const CXXRecordDec
@@ -1793,6 +1793,37 @@ void ItaniumCXXABI::EmitDestructorCall(CodeGenFunction
&CGF,
ThisTy, VTT, VTTTy, nullptr);
}
+// Check if any non-inline method has the specified attribute.
+template
+static bool CXXRecordNonInlineHasAttr(const CXXRecordDec
https://github.com/nga888 closed https://github.com/llvm/llvm-project/pull/92549
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/92549
>From 98f61948447ecbcbf538c247a274401941a87cd8 Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Wed, 15 May 2024 10:55:09 +0100
Subject: [PATCH] [clang] Make PS template DLL attribute propagation the same
as MSVC
@@ -0,0 +1,115 @@
+/// For a class that has a vtable and typeinfo symbol for RTTI, if a user marks
+/// either:
+///
+/// (a) The entire class as dllexport (dllimport)
+/// (b) Any non-inline method of the class as dllexport (dllimport)
+///
+/// then Clang must export the vta
@@ -1793,6 +1793,36 @@ void ItaniumCXXABI::EmitDestructorCall(CodeGenFunction
&CGF,
ThisTy, VTT, VTTTy, nullptr);
}
+// Check if any non-inline method has the specified attribute.
+template
+static bool CXXRecordNonInlineHasAttr(const CXXRecordDec
https://github.com/nga888 updated
https://github.com/llvm/llvm-project/pull/92579
>From d0b7fd1062c106f01da7d536185e1702bc09bd09 Mon Sep 17 00:00:00 2001
From: Andrew Ng
Date: Mon, 22 Apr 2024 19:29:01 +0100
Subject: [PATCH 1/2] [clang] Fix PS "selective" DLL import/export of vtable &
typeinfo
https://github.com/nga888 created
https://github.com/llvm/llvm-project/pull/92579
Prior to this patch, for "selective" DLL import/export, the vtable & typeinfo
would be imported/exported on the condition that all non-inline virtual methods
are imported/exported. This condition was based upon M
https://github.com/nga888 created
https://github.com/llvm/llvm-project/pull/92549
For PlayStation, make the propagation of DLL import/export attributes for
explicit template instantiations the same as MSVC and Windows Itanium.
>From 4bea6e9530460607f00820b8fcc9725e496c59e4 Mon Sep 17 00:00:00
nga888 wrote:
Sorry for the delay to reply but I've been more busy of late. I can confirm
that it was a downstream code path which was calling `getFile()` for a
`SyntheticSection` that was causing the assertion. This downstream code was
effectively ignoring a
nga888 wrote:
Hi @MaskRay,
I think that the addition of `ctx.internalFile` has broken this statement from
`class InputSectionBase`:
```
// The file which contains this section. Its dynamic type is always
// ObjFile, but in order to avoid ELFT, we use InputFile
Author: Andrew Ng
Date: 2023-02-09T10:39:09Z
New Revision: 0b704d9db7e15723922ee29c6f245d108a09c214
URL:
https://github.com/llvm/llvm-project/commit/0b704d9db7e15723922ee29c6f245d108a09c214
DIFF:
https://github.com/llvm/llvm-project/commit/0b704d9db7e15723922ee29c6f245d108a09c214.diff
LOG: [Su
Author: Andrew Ng
Date: 2023-01-30T10:44:32Z
New Revision: 2493a7016416c90038be5c816e12a7ad07cee054
URL:
https://github.com/llvm/llvm-project/commit/2493a7016416c90038be5c816e12a7ad07cee054
DIFF:
https://github.com/llvm/llvm-project/commit/2493a7016416c90038be5c816e12a7ad07cee054.diff
LOG: [cl
Author: Andrew Ng
Date: 2022-05-01T12:24:32+01:00
New Revision: 57c55165ebe8283b71ea785d2b0217119f8c5c51
URL:
https://github.com/llvm/llvm-project/commit/57c55165ebe8283b71ea785d2b0217119f8c5c51
DIFF:
https://github.com/llvm/llvm-project/commit/57c55165ebe8283b71ea785d2b0217119f8c5c51.diff
LOG
Author: anng
Date: Tue Feb 26 06:34:49 2019
New Revision: 354880
URL: http://llvm.org/viewvc/llvm-project?rev=354880&view=rev
Log:
[clang-format] SpaceBeforeParens for lambda expressions
Add support for lambda expressions to the SpaceBeforeParens formatting
option.
Differential Revision: https:/
43 matches
Mail list logo
