rnk wrote:
To be clear, you can repro the issue with the test case you have, just add
`-fsanitize=address` to flags to repro.
https://github.com/llvm/llvm-project/pull/90310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rnk wrote:
Hey, I went ahead and reverted this patch in
aa0776de464984e78ae1cc329bf541e9dd43631f because it is incompatible with ASan
ThinLTO builds. I think you have uncovered a latent issue in the ASan + thinlto
configuration that is not really the fault of this change, but I didn't see a
Author: Reid Kleckner
Date: 2024-05-10T21:28:13Z
New Revision: aa0776de464984e78ae1cc329bf541e9dd43631f
URL:
https://github.com/llvm/llvm-project/commit/aa0776de464984e78ae1cc329bf541e9dd43631f
DIFF:
https://github.com/llvm/llvm-project/commit/aa0776de464984e78ae1cc329bf541e9dd43631f.diff
rnk wrote:
I played with the idea of using LLVM packed structs (`<{ i129 }>`) to represent
something like this, but they don't work the way I expected them to do:
https://godbolt.org/z/M6hMYYhax
LLVM DataLayout's idea of `sizeof(i129)` is still rounded up from 17 bytes to
32 bytes.
Using
rnk wrote:
Thanks for the reminder, I missed the update.
https://github.com/llvm/llvm-project/pull/82815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/82815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -424,6 +424,34 @@ void
CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction ,
CGM.CreateRuntimeFunction(FTy, LaunchKernelName);
CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(),
LaunchKernelArgs);
+
+ // To prevent CUDA
@@ -424,6 +424,34 @@ void
CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction ,
CGM.CreateRuntimeFunction(FTy, LaunchKernelName);
CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(),
LaunchKernelArgs);
+
+ // To prevent CUDA
@@ -424,6 +424,34 @@ void
CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction ,
CGM.CreateRuntimeFunction(FTy, LaunchKernelName);
CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(),
LaunchKernelArgs);
+
+ // To prevent CUDA
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule ) {
+ // If the record is marked with the trivial_abi attribute, we don't
+
Author: Reid Kleckner
Date: 2024-04-29T22:09:09Z
New Revision: 1f44a0b1ff2daebe10b9916da228f7c0ba66827c
URL:
https://github.com/llvm/llvm-project/commit/1f44a0b1ff2daebe10b9916da228f7c0ba66827c
DIFF:
https://github.com/llvm/llvm-project/commit/1f44a0b1ff2daebe10b9916da228f7c0ba66827c.diff
rnk wrote:
Sorry for the delay, work life does its best to intervene.
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule ) {
+ // If the record is marked with the trivial_abi attribute, we don't
+
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/90151
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule ) {
+ // If the record is marked with the trivial_abi attribute, we don't
+
https://github.com/rnk requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule ) {
+ // If the record is marked with the trivial_abi attribute, we don't
+
rnk wrote:
So, I was completely unaware that trivial relocatability had been picked up at
all by WG21. Since the beginning of `trivial_abi`, I we were solidly in the
vendor-extension space trying to build non-standard but practical solutions to
real world problems, like the fact that we
https://github.com/rnk approved this pull request.
Thank you for polishing this corner of the driver interface! It's interesting
that they have an alternative separate spelling. I always felt like the
`/Fopath.cpp` pattern was a bit unreadable.
https://github.com/llvm/llvm-project/pull/88216
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+ int *p;
+ Trivial() : p(0) {}
+
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+ int *p;
+ Trivial() : p(0) {}
+
@@ -63,6 +63,10 @@ ABI Changes in This Version
MSVC uses a different mangling for these objects, compatibility is not
affected.
(#GH85423).
+- The attribute ``trivial_abi`` now works when targetting the Microsoft ABI.
Marking
rnk wrote:
It's overly
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/88751
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/88101
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
To restate the finding, 29% of .debug_info is describing class methods, at
least in Clang.
I think this is a useful mode, and we should land it as is. There are many
users up against the scaling limits of debug info size, and it's helpful to
have this as an option for
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/87209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/87209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
That's interesting! I wonder how long the /F flags have accepted trailing
colons. That form seems a lot more readable.
I went looking for examples of how to do this with fewer aliases, but it looks
like this is what is done currently:
rnk wrote:
> As a data point, I've been setting core.autocrlf=true on Windows for years.
If that's the case, my information is stale, which I accept.
> To be clear, this may do nothing on checkout if a user has set a config
> option.
That addresses my concerns.
rnk wrote:
I think it makes sense to remove carriage returns on checkin, but I'm not sure
it makes sense to add them back on checkout on Windows. Historically, it's been
really easy to write LLVM tests that fail when the source is checked out with
CRLF. Many Windows developers have noted that
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/86039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,81 @@
+//===-- sanitizer_win_thunk_interception.h -
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
https://github.com/rnk commented:
Is it feasible to create a migration path from the static runtime to the
dynamic runtime? As written, this requires users to update their ASan builds at
the same time that they take this update. Is it possible to leave the static
runtime behind, create a
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk created https://github.com/llvm/llvm-project/pull/82815
This behavior is true for all attributes, but this behavior can be surprising
for attributes which have function-wide effects, such as `optnone` and
`target`. Most other function attributes affect the prototype or
rnk wrote:
I'm short on time, so I can't respond to all the discussion here, but at a high
level, I agree with this direction and it's something I discussed with
Microsoft folks working on ASan in the past, so I'm happy to see it come
together.
There is a great deal of build configuration
https://github.com/rnk approved this pull request.
I think there are risks to shadowing `yvals_core.h`, but @CaseyCarter is at
least aware of it
[here](https://github.com/microsoft/STL/issues/3634#issuecomment-1904956652).
Once Clang ships its own intrin0.h header, the MSVC STL can adjust
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/80519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/80519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
Thanks! I added notes.
https://github.com/llvm/llvm-project/pull/80519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
What are the next steps to work to land this? We're interested to try this out
for Chrome!
https://github.com/llvm/llvm-project/pull/75425
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/80519
>From 6ab5ba3f970eaaea542fbed09cae17d3666df6b3 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Sat, 3 Feb 2024 00:18:42 +
Subject: [PATCH 1/4] wip
---
clang/lib/AST/Expr.cpp | 12
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/80519
>From 6ab5ba3f970eaaea542fbed09cae17d3666df6b3 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Sat, 3 Feb 2024 00:18:42 +
Subject: [PATCH 1/3] wip
---
clang/lib/AST/Expr.cpp | 12
rnk wrote:
> Also in the issue: #80510 you pointed out a crash bug. We should have the bug
> covered in the test case as well.
I think that is covered by the existing test case, instead of crashing, we now
reject with an error. In the future if we want to align with GCC as you
suggest, we'll
@@ -108,3 +109,22 @@ int computed_with_lambda = [] {
return result;
}();
#endif
+
+#if __cplusplus >= 201703L
+namespace DynamicFileScopeLiteral {
+// This covers the case where we have a file-scope compound literal with a
+// non-constant initializer in C++. Previously, we
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/80519
>From 6ab5ba3f970eaaea542fbed09cae17d3666df6b3 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Sat, 3 Feb 2024 00:18:42 +
Subject: [PATCH 1/2] wip
---
clang/lib/AST/Expr.cpp | 12
@@ -108,3 +109,22 @@ int computed_with_lambda = [] {
return result;
}();
#endif
+
+#if __cplusplus >= 201703L
+namespace DynamicFileScopeLiteral {
+// This covers the case where we have a file-scope compound literal with a
+// non-constant initializer in C++. Previously, we
https://github.com/rnk created https://github.com/llvm/llvm-project/pull/80519
This code was correct as written prior to C++17, which allowed bases to appear
in the initializer list.
Clang currently requires compound literal initializers at file scope to be
constants, which is how I tested
rnk wrote:
> > I would like some measurements so we can compare build times on Windows.
>
> I took some benchmarks with `-ftime-trace` on the parse times with and
> without this change.
> ...
> clang-cl built with this PR frontend took ~1368ms to parse. `intrin.h` took
> ~969ms to parse.
rnk wrote:
> > What I'd like to see is a pull request sent to
> > https://github.com/microsoft/stl with some agreement about how to structure
> > the ifdefs so we can use intrin0.h when it is available.
>
> Sounds good I'll do that.
Thanks!
> I was thinking I could use `__has_include_next`.
rnk wrote:
> If we land this as-is, it'll tank build time on Windows.
While this is true, I don't think it's the right tradeoff for us to leave Intel
intrinsics inaccessible for users who don't want to enable new
microarchitectural features globally with command line flags. You may recall
https://github.com/rnk approved this pull request.
> And it's a pretty straightforward extension to support (it just slightly
> modifies IR generation), so I don't think there's much long-term support
> burden.
I find that compelling, but make sure others' concerns are addressed.
rnk wrote:
@david-xl , Zequan posted an
[RFC](https://discourse.llvm.org/t/rfc-add-binary-profile-correlation-to-not-load-profile-metadata-sections-into-memory-at-runtime/74565/8)
for this. Is there a PGO tag, or something we can use to increase visibility
for PGO reviewers? I think most of
https://github.com/rnk commented:
> I assume that /volatile:ms is a legacy behavior that non-Windows OSes likely
> don't want to adopt.
That is correct, it is legacy behavior. However, I think this flag has
potential porting applications, similar to `-fshort-wchar`. I also think
operating
rnk wrote:
> @rnk -- what's the best way to check for compilation with microsoft's
> stardard C++ library?
If Clang is compiling with the MSVC STL headers, it should be defining
`_MSC_VER`, usually `-fms-compatibilty` has to be enabled to compile MSVC STL
headers. However, I searched, and
rnk wrote:
Here's a [GCC doc
link](https://gcc.gnu.org/onlinedocs/gcc/IA-64-Variable-Attributes.html). I
think matching GCC is sufficient motivation for me, I just didn't see it
mentioned.
https://github.com/llvm/llvm-project/pull/72078
___
rnk wrote:
Do folks feel like the attribute name is sufficiently descriptive? i.e. should
it be `__attribute__((code_model("asdf")))`? Are we aiming for GCC compat here?
What guides the naming choice?
https://github.com/llvm/llvm-project/pull/72078
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
> In the testcase, the lambda is just at global scope. Not sure what you're
> expecting to happen here.
I think that's what I'm trying to get at, this strategy is incomplete and
didn't work.
I think a principled fix to the general problem would be to incorporate the
anonymous
rnk wrote:
> I guess that's
> https://github.com/llvm/llvm-project/commit/b2615aa44d0cabd821b7afe5acdc847af9937c76...
> but I'm pretty sure we fixed -fdata-sections so the backend automatically
> generates comdats. So maybe we should just revert that.
That seems reasonable, however, there
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/71488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
Makes sense, small nit
https://github.com/llvm/llvm-project/pull/71488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3507,6 +3507,9 @@ static llvm::StoreInst
*findDominatingStoreToReturnValue(CodeGenFunction ) {
return nullptr;
// These aren't actually possible for non-coerced returns, and we
// only care about non-coerced returns on this code path.
+// All memory
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/71488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
> Do we really need to have all 4 variants of the 3 fortran runtime libraries?
> That's a lot of complexity. Can we pare it down to just static/dynamic? It's
> also sometimes possible to generate code that works in both the static and
> dynamic context, depending on what is in
rnk wrote:
Do we really need to have all 4 variants of the 3 fortran runtime libraries?
That's a lot of complexity. Can we pare it down to just static/dynamic? It's
also sometimes possible to generate code that works in both the static and
dynamic context, depending on what is in those
rnk wrote:
I think option 1 isn't really a permanent solution. We have lots of clang tools
that need to find the resource directory, and it should happen automatically.
For option 2, we'd have to reimplement that for every other clang tool that
needs to find resources, like LLD as well.
rnk wrote:
I think option 1 isn't really a permanent solution. We have lots of clang tools
that need to find the resource directory, and it should happen automatically.
For option 2, we'd have to reimplement that for every other clang tool that
needs to find resources, like LLD as well.
@@ -0,0 +1,38 @@
+// -*- C++ -*-
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -0,0 +1,38 @@
+// -*- C++ -*-
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+//
@@ -7,6 +7,8 @@
//===--===//
#include <__memory/aligned_alloc.h>
+#include <__overridable_function>
rnk wrote:
If this is only needed from files in src/, can the file be moved out of
rnk wrote:
We can definitely disable delayed template parsing in C++20 mode, I wouldn't
argue against that. Whoever actually does the work should decide how much
effort they are willing to put in. I'm just saying there are benefits to
starting the deprecation clock sooner, since it will
rnk wrote:
> I think there should be a proper Clang flag to control this, instead of
> requiring users to pass internal `-mllvm` flags. (Also the flag should be
> well documented.)
I believe Zequan did that at one point, but he ran into the problem that Rust
and Clang need to agree on the
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -Wconversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -Wbitfield-conversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armebv7-unknown-linux -Wbitfield-conversion \
+// RUN: -fsyntax-only -verify %s
+// RUN: %clang_cc1
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -Wconversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -Wbitfield-conversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armebv7-unknown-linux -Wbitfield-conversion \
+// RUN: -fsyntax-only -verify %s
+// RUN: %clang_cc1
rnk wrote:
I still support disabling delayed template parsing by default in all
configurations. Ultimately, this feature is a source of bugs, and we should
start the clock on its deprecation and removal. This, of course, involves real
work, and I haven't allocated any time (mine or others')
https://github.com/rnk approved this pull request.
Yep, we are fairly liberal about adding new clang options to the clang-cl mode,
especially if they are in the feature `-f` flag namespace, which we believe
will not conflict with MSVC flags.
https://github.com/llvm/llvm-project/pull/68921
https://github.com/rnk approved this pull request.
I was going to delegate the review to @aeubanks, who was the last one I'm aware
of to touch the strict vptr feature, but I think this is a pretty
straightforward fix.
https://github.com/llvm/llvm-project/pull/68169
https://github.com/rnk approved this pull request.
Yep, looks good to me.
https://github.com/llvm/llvm-project/pull/66816
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/67506
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/67066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/66120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/66120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
I wanted to make some minor naming suggestions, and I used the GitHub "edit
this file" feature for the first time to commit them as new commits to your
branch. I've never done this before, so I don't really know how it works, but
clang-format isn't available,
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/66120
>From 3fcfa303bd211f9a3382657012968cd3f7269db8 Mon Sep 17 00:00:00 2001
From: Ammarguellat
Date: Tue, 12 Sep 2023 11:25:19 -0700
Subject: [PATCH 1/7] [clang-cl] Fix for __FUNCTION__ in c++.
---
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/66120
>From 3fcfa303bd211f9a3382657012968cd3f7269db8 Mon Sep 17 00:00:00 2001
From: Ammarguellat
Date: Tue, 12 Sep 2023 11:25:19 -0700
Subject: [PATCH 1/7] [clang-cl] Fix for __FUNCTION__ in c++.
---
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/66120
>From 3fcfa303bd211f9a3382657012968cd3f7269db8 Mon Sep 17 00:00:00 2001
From: Ammarguellat
Date: Tue, 12 Sep 2023 11:25:19 -0700
Subject: [PATCH 1/6] [clang-cl] Fix for __FUNCTION__ in c++.
---
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/66120
>From 3fcfa303bd211f9a3382657012968cd3f7269db8 Mon Sep 17 00:00:00 2001
From: Ammarguellat
Date: Tue, 12 Sep 2023 11:25:19 -0700
Subject: [PATCH 1/6] [clang-cl] Fix for __FUNCTION__ in c++.
---
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/66120
>From 3fcfa303bd211f9a3382657012968cd3f7269db8 Mon Sep 17 00:00:00 2001
From: Ammarguellat
Date: Tue, 12 Sep 2023 11:25:19 -0700
Subject: [PATCH 1/5] [clang-cl] Fix for __FUNCTION__ in c++.
---
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/66120
>From 3fcfa303bd211f9a3382657012968cd3f7269db8 Mon Sep 17 00:00:00 2001
From: Ammarguellat
Date: Tue, 12 Sep 2023 11:25:19 -0700
Subject: [PATCH 1/5] [clang-cl] Fix for __FUNCTION__ in c++.
---
rnk wrote:
Seems reasonable to me, but I want @efriedma-quic to approve as well, if this
is a reasonable implementation of your direction.
https://github.com/llvm/llvm-project/pull/66816
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -2218,6 +2218,9 @@ printTo(raw_ostream , ArrayRef Args, const
PrintingPolicy ,
} else {
if (!FirstArg)
OS << Comma;
+ //if (Argument.getKind() == TemplateArgument::Type)
+ // OS << "class ";
+
rnk wrote:
I would move it into
rnk wrote:
It is true that the MSVC mangler doesn't generally canonicalize types, but I
think we can canonicalize in the `mangleTypeName` entry point, because it
exists to create unique type names for TBAA and CFI. You can audit the callers,
they all relate to either of those two things.
https://github.com/rnk commented:
This seems fine to me, but it's hard to understand if this is redundant with
some other "ParseFunction" scope from the tests. WDYT @MaskRay ?
https://github.com/llvm/llvm-project/pull/65268
___
cfe-commits mailing
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/66295
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 1204 matches
Mail list logo
