Re: [PATCH] D15267: For MS ABI, emit dllexport friend functions defined inline in class

rnk added inline comments. Comment at: include/clang/AST/ASTConsumer.h:58-64 @@ -57,5 +57,9 @@ /// \brief This callback is invoked each time an inline method definition is /// completed. virtual void HandleInlineMethodDefinition(CXXMethodDecl *D) {} + /// \brief This

Re: [PATCH] D16664: [CUDA] Generate CUDA's printf alloca in its function's entry block.

rnk added inline comments. Comment at: lib/CodeGen/CGCUDABuiltin.cpp:105-108 @@ -104,2 +104,6 @@ } else { -BufferPtr = Builder.Insert(new llvm::AllocaInst( +// Insert our alloca not into the current BB, but into the function's entry +// block. This is important bec

Re: [PATCH] D16478: Always build a new TypeSourceInfo for function templates with parameters

rnk added a comment. The fact that an instantiated type might point to decls from the template pattern seems like expected behavior. The parts of the template that are the same are supposed to be shared. Can we dig in to what is going wrong in parent map construction? http://reviews.llvm.org/

Re: [PATCH] D14467: [MS] Fix for bug 25013 - #pragma vtordisp is unknown inside functions.

rnk accepted this revision. rnk added a comment. This revision is now accepted and ready to land. I went ahead and ran some of your test cases through MSVC, and I agree with your results. This is pretty interesting behavior. Thanks for looking into it! Looks good. Comment at:

Re: r252853 - libclang: add clang_Cursor_getCXXManglings

This introduced a memory leak, which I'm testing a patch for. Aside from that, did you get Doug to review this? We probably want to be really careful about changing libclang's C API, so you should be more cautious here than you would be normally. On Wed, Nov 11, 2015 at 7:57 PM, Saleem Abdulrasoo

r253418 - Try to fix leak in CXStringSet from r252853

Author: rnk Date: Tue Nov 17 19:06:39 2015 New Revision: 253418 URL: http://llvm.org/viewvc/llvm-project?rev=253418&view=rev Log: Try to fix leak in CXStringSet from r252853 Modified: cfe/trunk/tools/libclang/CXString.cpp Modified: cfe/trunk/tools/libclang/CXString.cpp URL: http://llvm.org/

r253680 - [DebugInfo] Look through type sugar on union types when casting

Author: rnk Date: Fri Nov 20 11:41:12 2015 New Revision: 253680 URL: http://llvm.org/viewvc/llvm-project?rev=253680&view=rev Log: [DebugInfo] Look through type sugar on union types when casting Fixes PR25584. Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp cfe/trunk/test/CodeGenCXX/debug

r253694 - Thread Safety Analysis: Fix DenseMap iterator invalidation UAF

Author: rnk Date: Fri Nov 20 13:08:30 2015 New Revision: 253694 URL: http://llvm.org/viewvc/llvm-project?rev=253694&view=rev Log: Thread Safety Analysis: Fix DenseMap iterator invalidation UAF Rather than storing BeforeInfo in the DenseMap by value, this stores a unique_ptr to it, so that we can

Re: [PATCH] D14180: enable -fms-extensions by default on the mingw-w64 target

rnk added a comment. In http://reviews.llvm.org/D14180#299183, @martell wrote: > I tried testing __has_builtin(_InterlockedCompareExchangeAdd) as it seem to > not exist even when -fms-extensions is passed > Is this a bug or it is intended ? Neither Clang nor MSDN have anything by that name. D

Re: [PATCH] D14639: LLDB JIT needs android vector passing rules.

rnk added a subscriber: rnk. rnk added a comment. Were these changes made to AOSP Clang to match upstream GCC, or some custom Android version of GCC? Where would one go to find ground truth on how these types should be passed? http://reviews.llvm.org/D14639 _

Re: [PATCH] D14639: LLDB JIT needs android vector passing rules.

rnk accepted this revision. rnk added a reviewer: rnk. rnk added a comment. This revision is now accepted and ready to land. Ouch, that 2012 vector passing ABI break is a bummer. :( Comment at: lib/CodeGen/TargetInfo.cpp:5236 @@ +5235,3 @@ + if (const VectorType *VT = Ty->getAs

Re: [PATCH] D14639: LLDB JIT needs android vector passing rules.

rnk added a comment. lgtm http://reviews.llvm.org/D14639 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14180: enable -fms-extensions by default on the mingw-w64 target

rnk added a comment. In http://reviews.llvm.org/D14180#300193, @martell wrote: > @rnk you are correct. > mingw-w64 has been updated accordingly > > http://sourceforge.net/p/mingw-w64/mingw-w64/ci/61c374ded91a7de66f42f85a9f0cf9ee20/ > > So where do we go from here ? Let's disable the _Interlo

r254823 - Revert "[x86] Exclusion of incorrect include headers paths for MCU target"

Author: rnk Date: Fri Dec 4 19:52:14 2015 New Revision: 254823 URL: http://llvm.org/viewvc/llvm-project?rev=254823&view=rev Log: Revert "[x86] Exclusion of incorrect include headers paths for MCU target" This reverts commit r254195. From the description, I suspect that the wrong patch was commi

Re: r254195 - [x86] Exclusion of incorrect include headers paths for MCU target

It looks like the wrong patch got committed with the original description of D14954 . I reverted it in r254823. Feel free to commit the header change, it looks fine. On Fri, Nov 27, 2015 at 5:57 AM, Hal Finkel via cfe-commits < cfe-commits@lists.llvm.org> wrote: >

r254981 - [diagnostics] Avoid crashes while printing macro backtraces

Author: rnk Date: Mon Dec 7 19:08:09 2015 New Revision: 254981 URL: http://llvm.org/viewvc/llvm-project?rev=254981&view=rev Log: [diagnostics] Avoid crashes while printing macro backtraces When attempting to map a source into a given level of macro expansion, this code was ignoring the possibili

Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

It wasn't Chrome, it was some internal dependency on torch-cephes. I submitted a patch for it upstream: https://github.com/deepmind/torch-cephes/commit/9c4a97c90dc200ecbecb883e7230fe3c847954df It's not a pretty, though. I know LLVM IR rules are not C++ rules, but LLVM generally believes in NaN. It

[PATCH] D15384: Don't ask for the size of dependent integral types in template diffing

rnk created this revision. rnk added a reviewer: rsmith. rnk added a subscriber: cfe-commits. In the following example, we end up diffing 'A' against 'A<>'. template struct A {}; template > R bar(); A<> &foo() { return bar(); } It appears that we end up comparing the default argument of 'S

Re: [PATCH] D15373: Fix for bug 25786 - Assertion "Chunk.Kind == DeclaratorChunk::Function" failed with regparm attribute.

rnk added a subscriber: rnk. Comment at: include/clang/Sema/Sema.h:2938 @@ -2937,2 +2937,3 @@ bool CheckRegparmAttr(const AttributeList &attr, unsigned &value); + bool getCCFromAttr(const AttributeList &attr, CallingConv &CC); bool CheckCallingConvAttr(const AttributeList &

r255176 - Fix crash on invalid initialization with std::initializer_list

Author: rnk Date: Wed Dec 9 17:18:38 2015 New Revision: 255176 URL: http://llvm.org/viewvc/llvm-project?rev=255176&view=rev Log: Fix crash on invalid initialization with std::initializer_list It is possible for CheckListElementTypes to fail without filling in any initializer list elements. Modi

Re: [PATCH] D15399: MS inline ASM: mark the function noinline if the asm has labels (PR23715)

rnk accepted this revision. rnk added a comment. This revision is now accepted and ready to land. Looks terrible, please commit. Comment at: lib/CodeGen/CGStmt.cpp:2005 @@ -1998,3 +2004,3 @@ /* IsAlignStack */ false, AsmDialect); llvm::CallInst *Resu

[PATCH] D15436: Teach ActOnMemInitializers to cope with dependent bases and initializers

rnk created this revision. rnk added a reviewer: rsmith. rnk added a subscriber: cfe-commits. This both improves diagnostic quality and fixes crashes on invalid when we sneak dependent types into a constructor that isn't in a dependent context. Fixes PR24658 http://reviews.llvm.org/D15436 Files

Re: [PATCH] D15384: Don't ask for the size of dependent integral types in template diffing

rnk added a comment. Digging back through more history, I see that Richard added the call to getTypeSize in http://reviews.llvm.org/rL230603. http://reviews.llvm.org/D15384 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.o

Re: [PATCH] D15140: Update clang to use the updated LLVM EH instructions

rnk added inline comments. Comment at: lib/CodeGen/CGCall.cpp:3482 @@ +3481,3 @@ + &EHPersonality::get(*this) == + &EHPersonality::MSVC_CxxFrameHandler3) { +// The MSVC++ personality will implicitly terminate the program if an I gue

r255372 - Unify diagnostics for type defintitions in bad contexts

Author: rnk Date: Fri Dec 11 15:39:12 2015 New Revision: 255372 URL: http://llvm.org/viewvc/llvm-project?rev=255372&view=rev Log: Unify diagnostics for type defintitions in bad contexts The message for a type definition in an "if" condition was different from the other three for no particular rea

Re: [PATCH] D15478: [MS ABI] Don't rely on terminatepad

rnk accepted this revision. rnk added a comment. This revision is now accepted and ready to land. lgtm http://reviews.llvm.org/D15478 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r255382 - [clang-cl] Let /W4 map to -Wall -Wextra instead of just -Wall.

So, this change makes it impossible to download the build lots from the Windows self-hosting builders because of -Wunused-parameter errors. http://lab.llvm.org:8011/builders/clang-x86-win2008-selfhost/builds/5103/steps/build%20stage%202/logs/stdio Maybe that's an indication that users don't really

Re: [PATCH] D15518: [WinEH] Update clang to use operand bundles on call sites

rnk accepted this revision. rnk added a comment. This revision is now accepted and ready to land. lgtm http://reviews.llvm.org/D15518 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r255710 - [SEH] Use llvm.x86.seh.recoverfp for SEH filters on x64 as well as 32bit

Author: rnk Date: Tue Dec 15 17:47:40 2015 New Revision: 255710 URL: http://llvm.org/viewvc/llvm-project?rev=255710&view=rev Log: [SEH] Use llvm.x86.seh.recoverfp for SEH filters on x64 as well as 32bit Modified: cfe/trunk/lib/CodeGen/CGException.cpp cfe/trunk/test/CodeGen/exceptions-seh.

r255728 - Revert "[SEH] Use llvm.x86.seh.recoverfp for SEH filters on x64 as well as 32bit"

Author: rnk Date: Tue Dec 15 18:20:21 2015 New Revision: 255728 URL: http://llvm.org/viewvc/llvm-project?rev=255728&view=rev Log: Revert "[SEH] Use llvm.x86.seh.recoverfp for SEH filters on x64 as well as 32bit" This reverts commit r255710. Modified: cfe/trunk/lib/CodeGen/CGException.cpp

r255731 - Reland "[SEH] Use llvm.x86.seh.recoverfp for SEH filters on x64 as well as 32bit"

Author: rnk Date: Tue Dec 15 18:26:37 2015 New Revision: 255731 URL: http://llvm.org/viewvc/llvm-project?rev=255731&view=rev Log: Reland "[SEH] Use llvm.x86.seh.recoverfp for SEH filters on x64 as well as 32bit" I forgot to initialize RecoverFP. Modified: cfe/trunk/lib/CodeGen/CGException.c

r255744 - Print qualified display names when emitting CodeView

Author: rnk Date: Tue Dec 15 20:04:40 2015 New Revision: 255744 URL: http://llvm.org/viewvc/llvm-project?rev=255744&view=rev Log: Print qualified display names when emitting CodeView This is what debuggers expect. Words towards fixing PR21528. Added: cfe/trunk/test/CodeGenCXX/debug-info-cod

Re: r254195 - [x86] Exclusion of incorrect include headers paths for MCU target

No problem, stuff happens. :) On Wed, Dec 16, 2015 at 5:32 AM, Andrey Bokhanko wrote: > Correct patch committed in r255766. > > Yours, > Andrey > > On Wed, Dec 16, 2015 at 2:11 PM, Andrey Bokhanko > wrote: > > Reid, Hal, > > > > I'm really sorry for this -- indeed what I committed (by a mistake

Re: [PATCH] D15055: [X86] Better support for the MCU psABI

rnk accepted this revision. rnk added a comment. This revision is now accepted and ready to land. lgtm Comment at: lib/CodeGen/TargetInfo.cpp:838 @@ +837,3 @@ + bool shouldAggregateUseDirect(QualType Ty, CCState &State, bool &InReg, +bool &NeedsPadding) const; + bool shoul

[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

https://github.com/rnk approved this pull request. I think this looks good, then. Any other concerns? https://github.com/llvm/llvm-project/pull/96422 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinf

[clang] [X86][vectorcall] Do not consume register for indirect return value (PR #97939)

rnk wrote: Thanks! I was going to say, surely this can't be right, I was pretty confident that sret pointers consume registers for these conventions, but it looks like I was mistaken. I think this bug and code dates to 661f35b0c54c79805e6b17944b155c111bc39ec3 from 2014, which I think made the

[clang] [MS] Put dllexported inline global initializers in a comdat (PR #107154)

https://github.com/rnk created https://github.com/llvm/llvm-project/pull/107154 Follow-up to c19f4f8069722f6804086d4438a0254104242c46 to handle corner case of exported inline variables. Should fix #56485 >From cfb2cea5a4d4e0c1712e038692c4c5acee6b1f27 Mon Sep 17 00:00:00 2001 From: Reid Kleckne

[clang] [MS] Put dllexported inline global initializers in a comdat (PR #107154)

rnk wrote: I think there is no change here in our conformance on inline variable initialization order, except that non-discardable inline variables (achieved in this instance with dllexport, but perhaps there are other ways to do this. The classic case is explicit instantiation, which is unord

[clang] [MS] Put dllexported inline global initializers in a comdat (PR #107154)

https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/107154 >From cfb2cea5a4d4e0c1712e038692c4c5acee6b1f27 Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Tue, 3 Sep 2024 21:16:40 + Subject: [PATCH 1/2] [MS] Put dllexported inline global initializers in a comdat Foll

[clang] [MS] Put dllexported inline global initializers in a comdat (PR #107154)

rnk wrote: Yeah, I should've explicitly said I was working on updating the comment block. It needed significant surgery. Actually, this code could probably use more significant refactoring, but let's set that aside for now. > Does this impact non-MS targets? At the moment, I can't think of a

[clang] [MS] Put dllexported inline global initializers in a comdat (PR #107154)

https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/107154 >From cfb2cea5a4d4e0c1712e038692c4c5acee6b1f27 Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Tue, 3 Sep 2024 21:16:40 + Subject: [PATCH 1/3] [MS] Put dllexported inline global initializers in a comdat Foll

[clang] [llvm] [docs] Add a section on AI-generated content to the developer policy (PR #91014)

https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/91014 >From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 4 Sep 2024 16:52:49 + Subject: [PATCH 1/4] [clang] Fix FIXME in dynamic initializer emission, NFCI This poten

[clang] 601645c - [clang] Fix FIXME in dynamic initializer emission, NFCI

Author: Reid Kleckner Date: 2024-09-04T17:34:26Z New Revision: 601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6 URL: https://github.com/llvm/llvm-project/commit/601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6 DIFF: https://github.com/llvm/llvm-project/commit/601645c3b70e2a17d18779a3a51b8bc9ecdc9aa6.diff LOG:

[clang] [llvm] [docs] Add a section on AI-generated content to the developer policy (PR #91014)

https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/91014 >From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 4 Sep 2024 16:52:49 + Subject: [PATCH 1/4] [clang] Fix FIXME in dynamic initializer emission, NFCI This poten

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

@@ -215,6 +215,14 @@ struct NewUnspecified; SingleTemplate tmpl_single; UnspecTemplate tmpl_unspec; +// Member pointers used in base specifiers force an unspecified inheritance model +struct MemPtrInBase : UnspecTemplate {}; rnk wrote: Yes, but it's not clea

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

https://github.com/rnk commented: Sorry, looks like I wrote pending comments and didn't publish them https://github.com/llvm/llvm-project/pull/91990 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

@@ -13,3 +15,18 @@ template struct S3 { int T::*foo; }; + +template struct Base {}; +struct +S5 // #S5 +: +Base +// expected-error@-1 {{member pointer has incomplete base type 'S5'}} rnk wrote: I agree on the desired behavior, but doesn't this test show tha

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/91990 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [docs] Add a section on AI-generated content to the developer policy (PR #91014)

https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/91014 >From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 4 Sep 2024 16:52:49 + Subject: [PATCH 1/5] [clang] Fix FIXME in dynamic initializer emission, NFCI This poten

[clang] [llvm] [docs] Add a section on AI-generated content to the developer policy (PR #91014)

https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/91014 >From 88e4991013a05e26cece87d3989ad957a4e18e3d Mon Sep 17 00:00:00 2001 From: Reid Kleckner Date: Wed, 4 Sep 2024 16:52:49 + Subject: [PATCH 1/6] [clang] Fix FIXME in dynamic initializer emission, NFCI This poten

[clang] [llvm] [docs] Add a section on AI-generated content to the developer policy (PR #91014)

https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/91014 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CUDA] Emit used function list in deterministic order. (PR #102661)

@@ -950,6 +950,9 @@ void CodeGenModule::Release() { UsedArray.push_back(llvm::ConstantExpr::getPointerBitCastOrAddrSpaceCast( GetAddrOfGlobal(GD), Int8PtrTy)); } +// Sort decls by name to always emit them in deterministic order. rnk wrot

[clang] [Clang] [Sema] Error on reference types inside a union with msvc 1900+ (PR #102851)

rnk wrote: Something to consider is that `-fms-extensions` has, at various points, been used as a tool for making Windows code portable to Apple platforms. So, there may be users out there who use references in unions on non-Windows platforms. However, they presumably also build with modern ve

[clang] Reland "[Win32][ELF] Make CodeView a DebugInfoFormat only for COFF format", second try (PR #88245)

https://github.com/rnk approved this pull request. Sorry for the delay, looks good! https://github.com/llvm/llvm-project/pull/88245 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Reland "[Win32][ELF] Make CodeView a DebugInfoFormat only for COFF format", second try (PR #88245)

https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/88245 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Reland "[Win32][ELF] Make CodeView a DebugInfoFormat only for COFF format", second try (PR #88245)

@@ -5,15 +5,15 @@ // NO_GHASH-NOT: "-gcodeview-ghash" // default -// RUN: %clang_cl /Z7 -### -- %s 2>&1 | FileCheck -check-prefix=NO_GHASH %s +// RUN: %clang_cl -target x86_64-windows /Z7 -### -- %s 2>&1 | FileCheck -check-prefix=NO_GHASH %s // enabled -// RUN: %clang_cl /Z7

[clang] Reland "[Win32][ELF] Make CodeView a DebugInfoFormat only for COFF format", second try (PR #88245)

@@ -298,15 +298,15 @@ // FioRACE2: "-E" // FioRACE2: "-o" "foo.x" -// RUN: %clang_cl /Z7 /Foa.obj -### -- %s 2>&1 | FileCheck -check-prefix=ABSOLUTE_OBJPATH %s +// RUN: %clang_cl -target x86_64-windows /Z7 /Foa.obj -### -- %s 2>&1 | FileCheck -check-prefix=ABSOLUTE_OBJPATH %

[clang] [SEH] Ignore async exception flag when the environment is not MSVC (PR #88101)

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

[clang] Fix missing dtor in function calls accepting trivial ABI structs (PR #88751)

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

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

@@ -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 broa

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

@@ -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) {} + Tr

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

@@ -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) {} + Tr

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

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

[clang] [clang-cl] [Driver] Fix clang-cl driver supported colon options (PR #88216)

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 _

[clang] [clang][Sema] Track trivial-relocatability as a type trait (PR #84621)

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 couldn

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

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

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl GD) const { static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty, CodeGenModule &CGM) { + // If the record is marked with the trivial_abi attribute, we don'

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

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

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl GD) const { static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty, CodeGenModule &CGM) { + // If the record is marked with the trivial_abi attribute, we don'

[clang] [llvm] [CloneFunction][DebugInfo] Avoid cloning DILocalVariables of inlined functions (PR #75385)

rnk wrote: I'm not seeing how your example constitutes an ODR violation, or how merging these lambda types by mangled name is incorrect. They are equivalent in your example. It seems like the issue has more to do with the details of how exactly we do the merge, and where the metadata reference

[clang] Adds a pseudonym to clang"s windows mangler... (PR #97792)

https://github.com/rnk approved this pull request. Thanks, looks good, I'll wait for premerge checks to come back green before I merge it. https://github.com/llvm/llvm-project/pull/97792 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://

[clang] Adds a pseudonym to clang"s windows mangler... (PR #97792)

https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/97792 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

@@ -13,3 +15,18 @@ template struct S3 { int T::*foo; }; + +template struct Base {}; +struct +S5 // #S5 +: +Base +// expected-error@-1 {{member pointer has incomplete base type 'S5'}} rnk wrote: Should this be an error in Microsoft mode? Shouldn't we silentl

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

@@ -215,6 +215,14 @@ struct NewUnspecified; SingleTemplate tmpl_single; UnspecTemplate tmpl_unspec; +// Member pointers used in base specifiers force an unspecified inheritance model +struct MemPtrInBase : UnspecTemplate {}; rnk wrote: I guess this memptr ty

[clang] [Clang] Fix Microsoft ABI inheritance model when member pointer is used in a base specifier (PR #91990)

@@ -9015,11 +9015,20 @@ bool Sema::RequireCompleteTypeImpl(SourceLocation Loc, QualType T, if (const MemberPointerType *MPTy = T->getAs()) { if (!MPTy->getClass()->isDependentType()) { - if (getLangOpts().CompleteMemberPointers && - !MPTy->getClass()->getA

[clang] [Clang] [docs] [MSVC] Add sections on `__forceinline` and intrinsic behaviour differences between Clang and MSVC (PR #99426)

@@ -154,3 +154,133 @@ a hint suggesting how to fix the problem. As of this writing, Clang is able to compile a simple ATL hello world application. There are still issues parsing WRL headers for modern Windows 8 rnk wrote: "modern Windows 8" is obviously stale

[clang] [Clang] [docs] [MSVC] Add sections on `__forceinline` and intrinsic behaviour differences between Clang and MSVC (PR #99426)

@@ -154,3 +154,133 @@ a hint suggesting how to fix the problem. As of this writing, Clang is able to compile a simple ATL hello world application. There are still issues parsing WRL headers for modern Windows 8 apps, but they should be addressed soon. + +__forceinline behavior

[clang] [Clang] [docs] [MSVC] Add sections on `__forceinline` and intrinsic behaviour differences between Clang and MSVC (PR #99426)

https://github.com/rnk approved this pull request. https://github.com/llvm/llvm-project/pull/99426 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Adds a pseudonym to clang"s windows mangler... (PR #97792)

https://github.com/rnk commented: Sorry, I made this comment some time ago, but it looks like I never published it https://github.com/llvm/llvm-project/pull/97792 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/ma

[clang] Adds a pseudonym to clang"s windows mangler... (PR #97792)

https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/97792 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] Adds a pseudonym to clang"s windows mangler... (PR #97792)

@@ -1938,12 +1946,23 @@ void MicrosoftCXXNameMangler::mangleTemplateArgValue(QualType T, mangleNumber(V.getLValueOffset().getQuantity()); } else if (!V.hasLValuePath()) { // FIXME: This can only happen as an extension. Invent a mangling. -break; +

[clang] [clang-cl] [Sema] Support MSVC non-const lvalue to user-defined temporary reference (PR #99833)

https://github.com/rnk approved this pull request. I think this looks good, but I would appreciate another reviewer looking at the patch. https://github.com/llvm/llvm-project/pull/99833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://l

[clang] [clang-cl] [Sema] Support MSVC non-const lvalue to user-defined temporary reference (PR #99833)

https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/99833 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-cl] [Sema] Support MSVC non-const lvalue to user-defined temporary reference (PR #99833)

@@ -5138,7 +5148,11 @@ TryReferenceInit(Sema &S, Expr *Init, QualType DeclType, // -- Otherwise, the reference shall be an lvalue reference to a //non-volatile const type (i.e., cv1 shall be const), or the reference //shall be an rvalue reference. -

[clang] [clang codegen] Fix MS ABI detection of user-provided constructors. (PR #90151)

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

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl GD) const { static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty, CodeGenModule &CGM) { + // If the record is marked with the trivial_abi attribute, we don'

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

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

[clang] 1f44a0b - Make minor improvements to the creduce wrapper script

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 LOG:

[clang] [clang] Handle trivial_abi attribute for Microsoft ABI. (PR #88857)

@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl GD) const { static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty, CodeGenModule &CGM) { + // If the record is marked with the trivial_abi attribute, we don'

[clang] [CUDA] make kernel stub ICF-proof (PR #90155)

@@ -424,6 +424,34 @@ void CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction &CGF, CGM.CreateRuntimeFunction(FTy, LaunchKernelName); CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(), LaunchKernelArgs); + + // To prevent CU

[clang] [CUDA] make kernel stub ICF-proof (PR #90155)

@@ -424,6 +424,34 @@ void CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction &CGF, CGM.CreateRuntimeFunction(FTy, LaunchKernelName); CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(), LaunchKernelArgs); + + // To prevent CU

[clang] [CUDA] make kernel stub ICF-proof (PR #90155)

@@ -424,6 +424,34 @@ void CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction &CGF, CGM.CreateRuntimeFunction(FTy, LaunchKernelName); CGF.EmitCall(FI, CGCallee::forDirect(cudaLaunchKernelFn), ReturnValueSlot(), LaunchKernelArgs); + + // To prevent CU

[clang] Adds an arbitrary pseudonym to clang"s windows mangler... (PR #97792)

rnk wrote: I think this NTTP mangling code needs some significant updates, refactoring, and an increase in test coverage. I see cd93532dfc455255cb2fa553090d14aaa52b106b landed last May, probably when I was offline for a while. https://github.com/llvm/llvm-project/pull/97792 __

[clang] [clang][CGRecordLayout] Remove dependency on isZeroSize (PR #96422)

@@ -185,6 +203,18 @@ CALL_AO(PackedMembers) // CHECK: call void @llvm.memcpy.p0.p0.i64({{.*}} align 1 {{.*}} align 1 {{.*}}i64 16, i1 {{.*}}) // CHECK: ret ptr +// WithEmptyField copy-assignment: +// CHECK-LABEL: define linkonce_odr nonnull align {{[0-9]+}} dereferenceable({

[clang] [X86][vectorcall] Do not consume register for indirect return value (PR #97939)

rnk wrote: I lost the `__fastcall` or `__vectorcall` during editing, here's a fixed link: https://godbolt.org/z/46j33z8bc You can see the load from [edx] and store to [ecx]: ``` NonTrivial copy_nontrivial(NonTrivial *) PROC ; copy_nontrivial, COMDAT mov eax, DWORD PTR [edx]

[clang] [clang] Note that optnone and target attributes do not apply to nested functions (PR #82815)

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

[clang] [clang] Note that optnone and target attributes do not apply to nested functions (PR #82815)

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

[clang] [clang] Lower _BitInt(129+) to a different type in LLVM IR (PR #91364)

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 byt

[clang] aa0776d - Revert "[Pipelines] Do not run CoroSplit and CoroCleanup in LTO pre-link pipeline (#90310)" and related patches

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 LOG:

[clang] [llvm] [Pipelines] Do not run CoroSplit and CoroCleanup in LTO pre-link pipeline (PR #90310)

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

<    8   9   10   11   12   13   14   15   16   >