[PATCH] D62951: [analyzer][tests] Use normalize_plist in place of diff_plist (`tail` cases)

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rL362998: [analyzer][tests] Use normalize_plist in place of diff_plist (`tail` cases) (authored by hubert.reinterpretcast, c

[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

rjmccall added inline comments. Comment at: lib/CodeGen/CGDeclCXX.cpp:132 + Argument = CGM.getTargetCodeGenInfo().performAddrSpaceCast( + CGM, Addr.getPointer(), SrcAS, LangAS::opencl_global, DestTy); Anastasia wrote: > rjmccall wrote: > > Should

[PATCH] D62584: [OpenCL][PR42033] Deducing addr space with template parameter types

rjmccall added inline comments. Comment at: lib/Sema/TreeTransform.h:5363 +if (ResultType.getAddressSpace() != LangAS::Default && +(ResultType.getAddressSpace() != LangAS::opencl_private)) { SemaRef.Diag(TL.getReturnLoc().getBeginLoc(), Anastas

[PATCH] D62975: Require stdcall etc parameters to be complete on ODR use

This revision was automatically updated to reflect the committed changes. Closed by commit rL363000: Require stdcall etc parameters to be complete on ODR use (authored by rnk, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit: https:/

r363000 - Require stdcall etc parameters to be complete on ODR use

Author: rnk Date: Mon Jun 10 15:53:12 2019 New Revision: 363000 URL: http://llvm.org/viewvc/llvm-project?rev=363000&view=rev Log: Require stdcall etc parameters to be complete on ODR use Functions using stdcall, fastcall, or vectorcall with C linkage mangle in the size of the parameter pack. Calc

[PATCH] D50360: [Concepts] Requires Expressions

rsmith added inline comments. Comment at: include/clang/AST/DeclCXX.h:2051 +/// \code +/// template requires requires (T t) { {t++} -> Regular }; +/// \endcode The semicolon here is in the wrong place (should be before the final `}`, not after). ==

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

rjmccall added a reviewer: rsmith. rjmccall added a comment. Does this lead to C/C++ ABI mismatches? Should we just honor this in C++ as well by ignoring it when deciding to delete special members? Is taking such a general name a good idea if it's language-specific? Richard, thoughts? Repos

[PATCH] D63072: [clang] Fixing incorrect implicit deduction guides (PR41549)

rsmith accepted this revision. rsmith added a comment. This revision is now accepted and ready to land. Thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63072/new/ https://reviews.llvm.org/D63072 ___ cfe-commits mailing list cfe-commit

[PATCH] D59744: Fix i386 ABI "__m64" type bug

rjmccall added inline comments. Comment at: lib/CodeGen/TargetInfo.cpp:1005 bool IsMCUABI; + bool IsLinuxABI; unsigned DefaultNumRegisterParameters; mgorny wrote: > Maybe replace the two booleans with something alike `IsPassInMMXRegABI`? And > while at it

r363007 - Revert r362994 & co "[analyzer][tests] Add normalize_plist to replace diff_plist"

Author: rnk Date: Mon Jun 10 16:25:43 2019 New Revision: 363007 URL: http://llvm.org/viewvc/llvm-project?rev=363007&view=rev Log: Revert r362994 & co "[analyzer][tests] Add normalize_plist to replace diff_plist" Reverts r362998, r362996, and r362994 because the tests do not pass on Windows due t

r363009 - [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer

Author: arphaman Date: Mon Jun 10 16:32:42 2019 New Revision: 363009 URL: http://llvm.org/viewvc/llvm-project?rev=363009&view=rev Log: [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer in the compiler The function SetUpDiagnosticLog that was called from createDiagnostics did

[PATCH] D63101: [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer in the compiler

This revision was automatically updated to reflect the committed changes. Closed by commit rL363009: [Frontend] SetUpDiagnosticLog should handle unowned diagnostic consumer (authored by arphaman, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior

[PATCH] D63108: [OpenMP] Add support for handling declare target to clause when unified memory is required

gtbercea created this revision. gtbercea added reviewers: ABataev, AlexEichenberger, caomhin. Herald added subscribers: cfe-commits, jdoerfert, guansong. Herald added a project: clang. This patch adds support for the handling of the variables under the declare target to clause. The variables in

[PATCH] D62888: [NewPM] Port Sancov

chandlerc requested changes to this revision. chandlerc added a comment. This revision now requires changes to proceed. I would just change this to have the module pass loop over the functions -- that seems like it'll be much cleaner. As it is, I'm not seeing where the loop actually happens. But

[PATCH] D62225: [clang][NewPM] Fixing -O0 tests that are broken under new PM

chandlerc requested changes to this revision. chandlerc added a comment. This revision now requires changes to proceed. I think this ultimately needs to be split up into smaller patches. A bunch of these things can be landed independently. Here is my first cut at things to split out, each one in

r363018 - [X86] Enable intrinsics that convert float and bf16 data to each other

Author: pengfei Date: Mon Jun 10 18:17:28 2019 New Revision: 363018 URL: http://llvm.org/viewvc/llvm-project?rev=363018&view=rev Log: [X86] Enable intrinsics that convert float and bf16 data to each other Scalar version : _mm_cvtsbh_ss , _mm_cvtness_sbh Vector version: _mm512_cvtpbh_ps , _mm256_

[PATCH] D62363: [X86] Enable intrinsics that convert float and bf16 data to each other

This revision was automatically updated to reflect the committed changes. Closed by commit rL363018: [X86] Enable intrinsics that convert float and bf16 data to each other (authored by pengfei, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to

[PATCH] D33672: [analyzer] INT50-CPP. Do not cast to an out-of-range enumeration checker

NoQ added a comment. Herald added a subscriber: Charusso. Herald added a project: clang. Hey, i'm seeing a crash in this checker, would you like to look at it? It looks as if you're not being careful about dereferences/lvalue-to-rvalue-casts so it tries to compare `&e` to `e1`. **$ `cat repro.c

[PATCH] D62978: [analyzer] ReturnVisitor: Handle unknown ReturnStmts better

NoQ added inline comments. Comment at: clang/test/Analysis/diagnostics/find_last_store.c:9 void no_find_last_store() { - c *e = d(); // expected-note{{Calling 'd'}} - // expected-note@-1{{Returning from 'd'}} - // expected-note@-2{{'e' initialized here

[PATCH] D62926: [analyzer] ReturnVisitor: Bypass everything to see inlined calls

NoQ added inline comments. Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:842-849 + if (Optional CEE = Node->getLocationAs()) if (CEE->getCalleeContext()->getCallSite() == S) break; - if (auto SP = Node->getLocationAs()) -i

[PATCH] D63086: [analyzer][NoStoreFuncVisitor][NFC] Move methods out-of-line, turn some to static functions

NoQ accepted this revision. NoQ added a comment. This revision is now accepted and ready to land. Thx for the cleanup! Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:340 +private: + /// Attempts to find the region of interest in a given CXX decl, + /// by e

[PATCH] D62883: [analyzer] Track conditions of terminator statements on which the reported node depends on

NoQ added a comment. In D62883#1536894 , @Szelethus wrote: > I'm not sure how long it'll take for me to figure out what's wrong, but these > numbers are so ridiculous, I suspect a programming error rather then an > algorithmic issue. > > edit: I seem to

[PATCH] D63080: [analyzer] Track indices of arrays

NoQ added a comment. Whoa, this looks like a much needed improvement, i'm glad that you found it! Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1681 +trackExpressionValue( +LVNode, Arr->getIdx(), report, EnableNullFPSuppression); + --

[PATCH] D63093: [analyzer] WIP: MallocChecker: Release temporary CXXNewExpr

NoQ added a comment. In such cases i recommend starting with writing down a test. Like in TDD: first test, //then// code. The general direction doesn't seem reasonable to me; it introduces some pattern-matching for a specific scenario, but it's unclear why is this scenario a problem on its own

[PATCH] D63117: [analyzer] RetainCount: Add support for OSRequiredCast().

NoQ created this revision. NoQ added a reviewer: dcoughlin. Herald added subscribers: cfe-commits, Charusso, dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun. Herald added a project: clang. It's a new API for custom RTTI in Apple IOKit/DriverKit fra

[PATCH] D63118: [analyzer] DeadStores: Add a crude suppression files generated by DriverKit IIG.

NoQ created this revision. NoQ added a reviewer: dcoughlin. Herald added subscribers: cfe-commits, Charusso, dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun. Herald added a project: clang. IIG is a replacement for MIG in DriverKit: IIG is autogener

[PATCH] D44865: [libc++] Implement P0608R3 - A sane variant converting constructor

EricWF added inline comments. Comment at: include/variant:1128 +template +struct __overload +: __overload_bool<__overload<_Types...>, bool const volatile> {}; Do we even support volatile types in variant? Repository: rCXX libc++ CHANGES SINCE LAST ACTIO

[PATCH] D44865: [libc++] Implement P0608R3 - A sane variant converting constructor

zoecarver added inline comments. Comment at: include/variant:1128 +template +struct __overload +: __overload_bool<__overload<_Types...>, bool const volatile> {}; EricWF wrote: > Do we even support volatile types in variant? [[ http://eel.is/c++draft/variant.

[PATCH] D62988: Add an attribute to allow fields of non-trivial types in C unions

ahatanak added a comment. In D62988#1537082 , @rjmccall wrote: > Does this lead to C/C++ ABI mismatches? Should we just honor this in C++ as > well by ignoring it when deciding to delete special members? Is taking such > a general name a good idea if i

[PATCH] D44865: [libc++] Implement P0608R3 - A sane variant converting constructor

lichray updated this revision to Diff 203966. lichray added a comment. Add fail tests Repository: rCXX libc++ CHANGES SINCE LAST ACTION https://reviews.llvm.org/D44865/new/ https://reviews.llvm.org/D44865 Files: include/variant test/std/utilities/variant/variant.variant/variant.assign

[PATCH] D44865: [libc++] Implement P0608R3 - A sane variant converting constructor

lichray marked 2 inline comments as done. lichray added inline comments. Comment at: test/std/utilities/variant/variant.variant/variant.assign/T.pass.cpp:130 { using V = std::variant; static_assert(!std::is_assignable::value, "ambiguous"); mclow.lis

[libunwind] r363030 - Merging r360862:

Author: tstellar Date: Mon Jun 10 20:47:50 2019 New Revision: 363030 URL: http://llvm.org/viewvc/llvm-project?rev=363030&view=rev Log: Merging r360862: r360862 | mstorsjo | 2019-05-15 23:49:20 -0700 (Wed, 15 May 2019) | 12 l

[PATCH] D62831: [CodeGen][ObjC] Add attribute "arc_retain_agnostic" to ObjC globals that are retain-agnostic

gottesmm added a comment. This is exactly what I was imagining! This will enable the frontend to opt into this optimization without having to touch the optimizer. One nit: can we use a different name than "arc_retain_agnostic". Have you considered something like "arc_inert"? My fear is that at

[libunwind] r363031 - Creating release candidate rc2 from release_801 branch

Author: tstellar Date: Mon Jun 10 21:00:01 2019 New Revision: 363031 URL: http://llvm.org/viewvc/llvm-project?rev=363031&view=rev Log: Creating release candidate rc2 from release_801 branch Added: libunwind/tags/RELEASE_801/rc2/ - copied from r363030, libunwind/branches/release_80/ ___

[libclc] r363031 - Creating release candidate rc2 from release_801 branch

Author: tstellar Date: Mon Jun 10 21:00:01 2019 New Revision: 363031 URL: http://llvm.org/viewvc/llvm-project?rev=363031&view=rev Log: Creating release candidate rc2 from release_801 branch Added: libclc/tags/RELEASE_801/rc2/ - copied from r363030, libclc/branches/release_80/ _

[PATCH] D62831: [CodeGen][ObjC] Add attribute "arc_retain_agnostic" to ObjC globals that are retain-agnostic

ahatanak added a comment. I agree. Something like `arc_inert` is probably a better name in this case for the reason you mentioned. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62831/new/ https://reviews.llvm.org/D62831 ___

[PATCH] D59919: [Attributor] Deduce "returned" argument attribute

jdoerfert updated this revision to Diff 203973. jdoerfert added a comment. Update tests Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59919/new/ https://reviews.llvm.org/D59919 Files: clang/test/CodeGenOpenCL/as_type.cl llvm/include/llvm/Trans

[PATCH] D62244: [AMDGPU] Enable the implicit arguments for HIP (CLANG)

cdevadas updated this revision to Diff 203975. cdevadas added a comment. simplified the check in the test case. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62244/new/ https://reviews.llvm.org/D62244 Files: lib/CodeGen/TargetInfo.cpp test/CodeGenCUDA/amdgpu

[clang-tools-extra] r363034 - [clangd] Fix gcc warning by removing extra "; "

Author: uabelho Date: Mon Jun 10 23:02:01 2019 New Revision: 363034 URL: http://llvm.org/viewvc/llvm-project?rev=363034&view=rev Log: [clangd] Fix gcc warning by removing extra ";" Modified: clang-tools-extra/trunk/clangd/Format.cpp Modified: clang-tools-extra/trunk/clangd/Format.cpp URL: h

<    1   2