[PATCH] D46922: [checks/property-decls] Fix comment in clang-tidy/objc/PropertyDeclarationCheck.cpp ✍️

stephanemoore added a comment. In https://reviews.llvm.org/D46922#1125689, @benhamilton wrote: > > Is it possible to get someone to land this for me? I don't believe I have > > access to land it myself. > > Done. Thank you, kind sir 🙇 Repository: rL LLVM https://reviews.llvm.org/D46922

[PATCH] D47894: [clang]: Add support for "-fno-delete-null-pointer-checks"

jyknight added a comment. In https://reviews.llvm.org/D47894#1125653, @efriedma wrote: > The problem would come from propagating nonnull-ness from something which > isn't inherently nonnull. For example, strlen has a nonnull argument, so > `strlen(NULL)` is UB, therefore given `int z = strlen(

[PATCH] D47666: Refactored clang-fuzzer and added new (copy) files

kcc added a comment. Some feedback on the generated code: while (1){ let's not have the while loops inside the for loops for now. If the initial goal is to stress the loop optimizations (e.g. vectorizer), loops likes this are just a distraction for (int loop_ctr = 0 too verbose. Use 'i'm

[PATCH] D47894: [clang]: Add support for "-fno-delete-null-pointer-checks"

xbolva00 added a comment. In https://reviews.llvm.org/D47894#1125653, @efriedma wrote: > The problem would come from propagating nonnull-ness from something which > isn't inherently nonnull. For example, strlen has a nonnull argument, so > `strlen(NULL)` is UB, therefore given `int z = strlen(

[PATCH] D47894: [clang]: Add support for "-fno-delete-null-pointer-checks"

efriedma added a comment. For potential transforms based on nonnull, see https://reviews.llvm.org/D36656, I think? Repository: rC Clang https://reviews.llvm.org/D47894 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org

[PATCH] D47912: [CMake] Consider LLVM_APPEND_VC_REV when generating SVNVersion.inc

GBuella created this revision. GBuella added reviewers: beanz, bogner, hintonda. Herald added subscribers: cfe-commits, mgorny. This is merely a quickfix, due to being fustrated with waiting for ~70 objects to be linked each time following `git commit --amend`. When toggling LLVM_APPEND_VC_REV bet

r334240 - Revert "[Parse] Use CapturedStmt for @finally on MSVC"

Author: smeenai Date: Thu Jun 7 15:24:20 2018 New Revision: 334240 URL: http://llvm.org/viewvc/llvm-project?rev=334240&view=rev Log: Revert "[Parse] Use CapturedStmt for @finally on MSVC" This reverts commit r334224. This is causing buildbot failures on Windows, presumably because some tests do

[PATCH] D47912: [CMake] Consider LLVM_APPEND_VC_REV when generating SVNVersion.inc

smeenai added a comment. I believe LLVM_APPEND_VC_REV controls whether the revision is appended to LLVM version string (e.g. the output of `llvm-config --version`), whereas the SVNRevision.inc file (which is what's causing the relink after amending) is used for e.g. the `clang --version` output

[PATCH] D44788: Add an option to support debug fission on implicit ThinLTO.

yunlian updated this revision to Diff 150419. yunlian added a comment. Makes the default value to /path/to/binary_dwo, when DWO_DIR is provided, make the path to DWO_DIR/path/to/binary_dwo https://reviews.llvm.org/D44788 Files: include/clang/Driver/Options.td lib/Driver/ToolChains/CommonA

[PATCH] D47912: [CMake] Consider LLVM_APPEND_VC_REV when generating SVNVersion.inc

GBuella added a comment. In https://reviews.llvm.org/D47912#1125803, @smeenai wrote: > I believe LLVM_APPEND_VC_REV controls whether the revision is appended to > LLVM version string (e.g. the output of `llvm-config --version`), whereas the > SVNRevision.inc file (which is what's causing the re

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

rnk accepted this revision. rnk added a comment. lgtm Repository: rC Clang https://reviews.llvm.org/D47853 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47862: [CodeGen] Always use MSVC personality for windows-msvc targets

rnk added inline comments. Comment at: lib/CodeGen/CGException.cpp:134-135 const llvm::Triple &T = Target.getTriple(); + if (T.isWindowsMSVCEnvironment()) +return EHPersonality::MSVC_CxxFrameHandler3; + I guess previously we carefully arranged to go to wh

r334243 - [Frontend] Disallow non-MSVC exception models for windows-msvc targets

Author: smeenai Date: Thu Jun 7 15:54:54 2018 New Revision: 334243 URL: http://llvm.org/viewvc/llvm-project?rev=334243&view=rev Log: [Frontend] Disallow non-MSVC exception models for windows-msvc targets The windows-msvc target is used for MSVC ABI compatibility, including the exceptions model.

[PATCH] D47853: [Frontend] Disallow non-MSVC exception models for windows-msvc targets

This revision was automatically updated to reflect the committed changes. Closed by commit rL334243: [Frontend] Disallow non-MSVC exception models for windows-msvc targets (authored by smeenai, committed by ). Herald added a subscriber: llvm-commits. Repository: rL LLVM https://reviews.llvm.or

r334244 - [X86] Add builtins for shuff32x4/shuff64x2/shufi32x4/shuff64x2 to enable target feature checking and immediate range checking.

Author: ctopper Date: Thu Jun 7 16:03:08 2018 New Revision: 334244 URL: http://llvm.org/viewvc/llvm-project?rev=334244&view=rev Log: [X86] Add builtins for shuff32x4/shuff64x2/shufi32x4/shuff64x2 to enable target feature checking and immediate range checking. Modified: cfe/trunk/include/cla

r334249 - [X86] Add builtins for blend with immediate control to enforce target feature requirements and check immediate range.

Author: ctopper Date: Thu Jun 7 17:00:21 2018 New Revision: 334249 URL: http://llvm.org/viewvc/llvm-project?rev=334249&view=rev Log: [X86] Add builtins for blend with immediate control to enforce target feature requirements and check immediate range. Modified: cfe/trunk/include/clang/Basic/

[PATCH] D47862: [CodeGen] Always use MSVC personality for windows-msvc targets

smeenai added inline comments. Comment at: lib/CodeGen/CGException.cpp:134-135 const llvm::Triple &T = Target.getTriple(); + if (T.isWindowsMSVCEnvironment()) +return EHPersonality::MSVC_CxxFrameHandler3; + rnk wrote: > I guess previously we carefully arr

[PATCH] D47920: Made loop_proto more "vectorizable"

emmettneyman created this revision. emmettneyman added reviewers: kcc, vitalybuka, morehouse. Herald added a subscriber: cfe-commits. Edited loop_proto and its converter to make more "vectorizable" code - Removed all while loops - Can only index into array with induction variable Repository:

[PATCH] D47687: fix: [Bug 18971] - Missing -Wparentheses warning

rnk added subscribers: dexonsmith, chandlerc. rnk added a comment. @dexonsmith is there someone from Apple who can comment on rdar://8678458 and the merits of disabling this warning in macros? I strongly suspect the original report was dealing with code like `assert(x || y && "str");`, if so we

[PATCH] D47862: [CodeGen] Always use MSVC personality for windows-msvc targets

rnk accepted this revision. rnk added inline comments. This revision is now accepted and ready to land. Comment at: lib/CodeGen/CGException.cpp:134-135 const llvm::Triple &T = Target.getTriple(); + if (T.isWindowsMSVCEnvironment()) +return EHPersonality::MSVC_CxxFrameHand

[PATCH] D47920: Made loop_proto more "vectorizable"

morehouse accepted this revision. morehouse added a comment. This revision is now accepted and ready to land. Looks like a good start. Repository: rC Clang https://reviews.llvm.org/D47920 ___ cfe-commits mailing list cfe-commits@lists.llvm.org ht

r334251 - Reapply "[Parse] Use CapturedStmt for @finally on MSVC"

Author: smeenai Date: Thu Jun 7 17:30:00 2018 New Revision: 334251 URL: http://llvm.org/viewvc/llvm-project?rev=334251&view=rev Log: Reapply "[Parse] Use CapturedStmt for @finally on MSVC" This reapplies r334224 and adds explicit triples to some tests to fix them on Windows (where otherwise they

r334252 - [clang-fuzzer] Made loop_proto more "vectorizable".

Author: morehouse Date: Thu Jun 7 17:33:35 2018 New Revision: 334252 URL: http://llvm.org/viewvc/llvm-project?rev=334252&view=rev Log: [clang-fuzzer] Made loop_proto more "vectorizable". Edited loop_proto and its converter to make more "vectorizable" code according to kcc's comment in D47666 -

[PATCH] D47920: Made loop_proto more "vectorizable"

This revision was automatically updated to reflect the committed changes. Closed by commit rC334252: [clang-fuzzer] Made loop_proto more "vectorizable". (authored by morehouse, committed by ). Changed prior to commit: https://reviews.llvm.org/D47920?vs=150435&id=150436#toc Repository: rC Cla

[PATCH] D47862: [CodeGen] Always use MSVC personality for windows-msvc targets

This revision was automatically updated to reflect the committed changes. Closed by commit rC334253: [CodeGen] Always use MSVC personality for windows-msvc targets (authored by smeenai, committed by ). Changed prior to commit: https://reviews.llvm.org/D47862?vs=150243&id=150437#toc Repository:

r334253 - [CodeGen] Always use MSVC personality for windows-msvc targets

Author: smeenai Date: Thu Jun 7 17:41:01 2018 New Revision: 334253 URL: http://llvm.org/viewvc/llvm-project?rev=334253&view=rev Log: [CodeGen] Always use MSVC personality for windows-msvc targets The windows-msvc target is meant to be ABI compatible with MSVC, including the exception handling. E

r334256 - [X86] Add builtins for vpermilps/pd instructions to enable target feature checking.

Author: ctopper Date: Thu Jun 7 17:59:27 2018 New Revision: 334256 URL: http://llvm.org/viewvc/llvm-project?rev=334256&view=rev Log: [X86] Add builtins for vpermilps/pd instructions to enable target feature checking. Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def cfe/trunk/lib/

[PATCH] D47894: [clang]: Add support for "-fno-delete-null-pointer-checks"

srhines added a comment. In https://reviews.llvm.org/D47894#1125728, @jyknight wrote: > In https://reviews.llvm.org/D47894#1125653, @efriedma wrote: > > > The problem would come from propagating nonnull-ness from something which > > isn't inherently nonnull. For example, strlen has a nonnull ar

[PATCH] D47687: fix: [Bug 18971] - Missing -Wparentheses warning

dexonsmith added a comment. In https://reviews.llvm.org/D47687#1125926, @rnk wrote: > @dexonsmith is there someone from Apple who can comment on rdar://8678458 and > the merits of disabling this warning in macros? I strongly suspect the > original report was dealing with code like `assert(x ||

r334261 - [X86] Add subvector insert and extract builtins to enable target feature checking and immediate range checking.

Author: ctopper Date: Thu Jun 7 20:24:47 2018 New Revision: 334261 URL: http://llvm.org/viewvc/llvm-project?rev=334261&view=rev Log: [X86] Add subvector insert and extract builtins to enable target feature checking and immediate range checking. Test changes are due to differences in how we gene

r334264 - [X86] Fix some typecasts in intrinsic headers that I messed up in r334261.

Author: ctopper Date: Thu Jun 7 21:09:14 2018 New Revision: 334264 URL: http://llvm.org/viewvc/llvm-project?rev=334264&view=rev Log: [X86] Fix some typecasts in intrinsic headers that I messed up in r334261. This was caught by the Header tests, but not the CodeGen tests. Modified: cfe/trunk

[PATCH] D47687: fix: [Bug 18971] - Missing -Wparentheses warning

Higuoxing added a comment. In https://reviews.llvm.org/D47687#1125926, @rnk wrote: > @dexonsmith is there someone from Apple who can comment on rdar://8678458 and > the merits of disabling this warning in macros? I strongly suspect the > original report was dealing with code like `assert(x || y

r334265 - [X86] Add builtins for pshufd, pshuflw, and pshufhw to enable target feature and immediate range checking.

Author: ctopper Date: Thu Jun 7 23:13:16 2018 New Revision: 334265 URL: http://llvm.org/viewvc/llvm-project?rev=334265&view=rev Log: [X86] Add builtins for pshufd, pshuflw, and pshufhw to enable target feature and immediate range checking. Modified: cfe/trunk/include/clang/Basic/BuiltinsX86

[PATCH] D47687: fix: [Bug 18971] - Missing -Wparentheses warning

lebedev.ri added a comment. In https://reviews.llvm.org/D47687#1126032, @Higuoxing wrote: > In https://reviews.llvm.org/D47687#1125926, @rnk wrote: > > > @dexonsmith is there someone from Apple who can comment on rdar://8678458 > > and the merits of disabling this warning in macros? I strongly s

<    1   2