ahatanak added inline comments.
Comment at: test/Sema/nonnull.c:171
+
+void pr31040(char *p __attribute__((nonnull)));
+void pr31040(char *p) {}
Is this not pr30828?
https://reviews.llvm.org/D26800
___
cfe-commits
echuraev updated this revision to Diff 79508.
https://reviews.llvm.org/D27099
Files:
include/clang/Basic/DiagnosticSemaKinds.td
lib/Sema/SemaDecl.cpp
test/SemaOpenCL/event_t.cl
test/SemaOpenCL/invalid-clk-events-cl2.0.cl
test/SemaOpenCL/invalid-pipes-cl2.0.cl
Index: test/SemaOpenCL/inv
hfinkel added a comment.
This seems like a great idea. btw, do you know about Cling
(https://root.cern.ch/cling)?
Repository:
rL LLVM
https://reviews.llvm.org/D27180
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/c
flx created this revision.
flx added reviewers: alexfh, sbenza, aaron.ballman.
flx added a subscriber: cfe-commits.
flx set the repository for this revision to rL LLVM.
flx added a project: clang-tools-extra.
Herald added a subscriber: JDevlieghere.
This fixes a bug where the performance-unnecessa
AntonBikineev added a subscriber: cfe-commits.
AntonBikineev updated this revision to Diff 79491.
https://reviews.llvm.org/D27162
Files:
include/chrono
test/std/utilities/time/time.duration/time.duration.arithmetic/op_++.pass.cpp
test/std/utilities/time/time.duration/time.duration.arithmet
khazem created this revision.
khazem added reviewers: spyffe, a.sidorin.
khazem added subscribers: cfe-commits, phosek, seanklein, klimek.
Some of this patch comes from Aleksei's branch [1], with minor revisions. I've
added unit tests and AST Matcher support. Copying in Manuel in case there is no
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.
This looks fine to me - though I wonder if the compiler can hoist `*__first2`
w/o us helping it.
https://reviews.llvm.org/D26991
___
c
Committed as r288097.
On 28 November 2016 at 05:27, Joshua Hurwitz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Thanks Richard for looking at the revised patch.
>
> On Mon, Nov 21, 2016 at 1:50 PM Richard Smith
> wrote:
>
>> This looks good to me. (While we could generalize this furthe
Author: rsmith
Date: Mon Nov 28 19:35:17 2016
New Revision: 288097
URL: http://llvm.org/viewvc/llvm-project?rev=288097&view=rev
Log:
Add a warning for 'main' returning 'true' or 'false'.
Patch by Joshua Hurwitz!
Added:
cfe/trunk/test/Sema/warn-main-returns-bool-literal.cpp
Modified:
cfe/
smeenai added a comment.
Ping.
https://reviews.llvm.org/D26950
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smeenai added a comment.
Ping.
Lmk if there's any other tests I should run on this to ensure there's no
functional difference.
https://reviews.llvm.org/D26949
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/ma
smeenai added a comment.
Ping.
https://reviews.llvm.org/D26657
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
spyffe created this revision.
spyffe added reviewers: a.sidorin, beanz, loladiro, v.g.vassilev.
spyffe added a subscriber: cfe-commits.
spyffe set the repository for this revision to rL LLVM.
Herald added a subscriber: mgorny.
LLVM's JIT is now the foundation of dynamic-compilation features for ma
joerg updated this revision to Diff 79482.
joerg added a comment.
Move implementation into the Clang class, keep track of the raw_fd_stream. This
avoids reopening it on multiple inputs and removes the need for append mode.
Short circuit the function when -### is present. Add proper diagnostics o
Author: rnk
Date: Mon Nov 28 18:39:37 2016
New Revision: 288093
URL: http://llvm.org/viewvc/llvm-project?rev=288093&view=rev
Log:
Use ${:uid} to generate unique MS asm labels, not {:uid}
Modified:
cfe/trunk/lib/Sema/SemaStmtAsm.cpp
cfe/trunk/test/CodeGen/mozilla-ms-inline-asm.c
cfe/tr
dcoughlin accepted this revision.
dcoughlin added a comment.
This revision is now accepted and ready to land.
This is great!
Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:205
- // We need to be careful about treating a derived type's value as
- // bindings for a base t
Author: rnk
Date: Mon Nov 28 17:58:04 2016
New Revision: 288089
URL: http://llvm.org/viewvc/llvm-project?rev=288089&view=rev
Log:
Avoid lambdas in default member initializers to work around clang bug
On Windows, Clang is mangling lambdas in default member initializers
incorrectly. See PR31197.
T
joerg added a comment.
Can I interprete that as LGTM otherwise?
Repository:
rL LLVM
https://reviews.llvm.org/D27138
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ahatanak added a comment.
I wonder whether it is possible to avoid calling
DeclScopeObj.EnterDeclaratorScope at ParseDecl.cpp:5317 instead of fixing
Sema::ActOnCXXEnterDeclaratorScope?
I believe it's calling EnterDeclaratorScope to enable name lookup when a
namespace-member variable is defined
On 28 November 2016 at 15:33, John McCall via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On Mon, Nov 28, 2016 at 2:48 PM, Richard Smith
> wrote:
>
>> (Dropping Phabricator, since this isn't really about D27163...)
>>
>> On 28 November 2016 at 14:27, John McCall via Phabricator via cfe-com
On Mon, Nov 28, 2016 at 2:48 PM, Richard Smith
wrote:
> (Dropping Phabricator, since this isn't really about D27163...)
>
> On 28 November 2016 at 14:27, John McCall via Phabricator via cfe-commits
> wrote:
>
>> In https://reviews.llvm.org/D27163#607100, @rsmith wrote:
>> > C has rather differen
- remove devtoolset-1 (obsoleted gcc 4.7)
- add devtoolset-6 (gcc 6.2+)
(There is no devtoolset-5, RH switched to gcc major version numbering.)
Please apply, I don't have commit access.
Thanks,
Michael
diff -ru a/lib/Driver/ToolChains.cpp b/lib/Driver/ToolChains.cpp
--- a/lib/Driver/ToolChai
lukasza added a comment.
Forcing shallow matching means that unit test below will stop passing after
this CL.
TEST(HasDeclaration, DeepTagType) {
std::string input =
"class Foo {};\n"
"using Bar = Foo;\n"
"void Function(Bar param) {}\n";
// Matcher for declar
Great, I'll get this working soon and attach a new patch :)
On Mon, 28 Nov 2016 at 14:27 Hans Wennborg wrote:
> On Mon, Nov 28, 2016 at 11:11 AM, Antonio Maiorano
> wrote:
> >> It's built with the script in utils/release/build_llvm_package.bat
> > which I run manually on my machine once every f
MathieuDuponchelle added a comment.
I get tons of errors when running these tests with python 3 (version 3.4.3)
with a fresh build of clang and llvm. The number of failures vs errors vary
wildly between each invocation, the number of total failures + errors stays the
same, which led me to think
Okay, I'll see if upgrading to the 2015 assemblies would allow the VSIX to
keep working in older versions of VS.
Still waiting on an answer to this question:
> In either case, though, I must ask: how is the offical vsix that's
available on http://llvm.org/builds/ get built? Is it part of an autom
> It's built with the script in utils/release/build_llvm_package.bat
which I run manually on my machine once every few weeks.
Okay, that's good news. So the simplest path to success would be to require
the user to either pass the path to CMake via an arg like -DNUGET_EXE_PATH,
or if it's not defin
Unfortunately, vsvarsall doesn't bring nuget onto path. I shared a few
links earlier about this:
https://nuget.codeplex.com/workitem/3615
http://stackoverflow.com/questions/22300375/nuget-auto-package-restore-does-not-work-with-msbuild/23935892#23935892
Your idea about -DMSVC_NUGET_PATH for CMake
Ah, no, that's not what I meant. The required referenced assemblies are
versions that are normally installed with VS 2010.
The first time I worked on this, I had upgraded the referenced assemblies
to the ones that ship with VS 2015, but then there was question of whether
or not the VSIX would cont
Hi Hans,
I saw that on September 15th, you checked in a change: clang-format VS
plugin: upgrade the project files to VS2015.
When I open the latest version of ClangFormat.sln on a machine that has
only VS 2015, it doesn't build. The reason is that some of the referenced
assemblies are from VS 201
Okay, that's fine, I'll go for that and if all looks good, will attach a
patch.
Thanks.
On Thu, 24 Nov 2016 at 15:09 Zachary Turner wrote:
> I would use the first solution. We lock ourselves to specific versions of
> vs, so i think it's fine to do the same with the assemblies and deal with
> it
Hi again,
I've made the changes so that the required assemblies are committed, so now
we can build the clang-format-vsix with just VS 2015. Since the patch set
is around 9 mb, I'm providing a link to it on my Dropbox (if you'd rather I
attach it, let me know):
https://dl.dropboxusercontent.com/u/
zaks.anna added a comment.
Not sure if we should make pure vs not an option so that users could turn the
checking off. Is there a way to suppress the warning?
Comment at: lib/StaticAnalyzer/Checkers/VirtualCallChecker.cpp:210
+ if (isPure)
+os << "pure ";
+
--
rnk added a comment.
Adding the flag seems OK, but I'd rather not make the default setting be
target-dependent, if that's workable.
Repository:
rL LLVM
https://reviews.llvm.org/D27163
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http:
hiraditya updated this revision to Diff 79463.
hiraditya added a comment.
Removed unused code.
https://reviews.llvm.org/D26991
Files:
libcxx/include/algorithm
Index: libcxx/include/algorithm
===
--- libcxx/include/algorithm
+++
(Dropping Phabricator, since this isn't really about D27163...)
On 28 November 2016 at 14:27, John McCall via Phabricator via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> In https://reviews.llvm.org/D27163#607100, @rsmith wrote:
> > C has rather different and much less useful TBAA rules
>
>
hiraditya added a comment.
@mclow.lists
I can remove this and update this patch with the load hoisted, if this is okay.
https://reviews.llvm.org/D26991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/li
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288083: IRGen: Remove all uses of CreateDefaultAlignedLoad.
(authored by pcc).
Changed prior to commit:
https://reviews.llvm.org/D27157?vs=79436&id=79462#toc
Repository:
rL LLVM
https://reviews.llvm
Author: pcc
Date: Mon Nov 28 16:30:21 2016
New Revision: 288083
URL: http://llvm.org/viewvc/llvm-project?rev=288083&view=rev
Log:
IRGen: Remove all uses of CreateDefaultAlignedLoad.
Differential Revision: https://reviews.llvm.org/D27157
Modified:
cfe/trunk/lib/CodeGen/CGBuilder.h
cfe/tru
rsmith added inline comments.
Comment at: lib/Frontend/FrontendActions.cpp:227
+IsBuiltin = true;
+ addHeaderInclude(H.NameAsWritten, Includes, LangOpts, Module->IsExternC,
+ IsBuiltin /*AlwaysInclude*/);
I don't understand why
rjmccall added inline comments.
Comment at: clang/lib/CodeGen/CGBuilder.h:126
// FIXME: these "default-aligned" APIs should be removed,
// but I don't feel like fixing all the builtin code right now.
llvm::StoreInst *CreateDefaultAlignedStore(llvm::Value *Val,
--
Author: rjmccall
Date: Mon Nov 28 16:18:30 2016
New Revision: 288080
URL: http://llvm.org/viewvc/llvm-project?rev=288080&view=rev
Log:
Hide the result of building a constant initializer. NFC.
Modified:
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/
Author: rjmccall
Date: Mon Nov 28 16:18:27 2016
New Revision: 288079
URL: http://llvm.org/viewvc/llvm-project?rev=288079&view=rev
Log:
ConstantBuilder -> ConstantInitBuilder for clarity, and
move the member classes up to top level to allow forward
declarations to name them. NFC.
Modified:
cf
Author: rjmccall
Date: Mon Nov 28 16:18:33 2016
New Revision: 288081
URL: http://llvm.org/viewvc/llvm-project?rev=288081&view=rev
Log:
Make CGVTables use ConstantInitBuilder. NFC.
Modified:
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/CodeGen/CGVTables.h
cfe/trunk/lib/CodeGen/It
rjmccall added a comment.
In https://reviews.llvm.org/D27163#607100, @rsmith wrote:
> In https://reviews.llvm.org/D27163#607078, @rsmith wrote:
>
> > A target-specific default for this, simply because there's a lot of code on
> > Darwin that happens to violate this language rule, doesn't make se
bruno added a comment.
@rsmith ping!
https://reviews.llvm.org/D26267
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rsmith added a comment.
In https://reviews.llvm.org/D27163#607078, @rsmith wrote:
> A target-specific default for this, simply because there's a lot of code on
> Darwin that happens to violate this language rule, doesn't make sense to me.
... but rjmccall's explanation of the problem helps. Th
bruno added inline comments.
Comment at: lib/Sema/SemaExpr.cpp:8064
+ ScalarCast = CK_FloatingCast;
+} else if (ScalarTy->isIntegralType(S.Context)) {
+ // Determine if the integer constant can be expressed as a floating point
sdardis wrote:
> bruno
rsmith added a comment.
A target-specific default for this, simply because there's a lot of code on
Darwin that happens to violate this language rule, doesn't make sense to me.
Basing the behavior on whether a `-Wreturn-type` warning would have been
emitted seems like an extremely strange heuri
mehdi_amini added inline comments.
Comment at: test/CodeGenCXX/return.cpp:21
+ // CHECK-NOSTRICT-NEXT: load
+ // CHECK-NOSTRICT-NEXT: ret i32
+ // CHECK-NOSTRICT-NEXT: }
rjmccall wrote:
> mehdi_amini wrote:
> > Quuxplusone wrote:
> > > Can you explain why a lo
spyffe accepted this revision.
spyffe added a comment.
This revision is now accepted and ready to land.
Yeah, that test looks great! Thanks!
Comment at: lib/AST/ASTImporter.cpp:496
+return false;
+ if (DN1->isIdentifier())
+return IsStructurallyEquivalent(
rjmccall added inline comments.
Comment at: test/CodeGenCXX/return.cpp:21
+ // CHECK-NOSTRICT-NEXT: load
+ // CHECK-NOSTRICT-NEXT: ret i32
+ // CHECK-NOSTRICT-NEXT: }
mehdi_amini wrote:
> Quuxplusone wrote:
> > Can you explain why a load from an uninitialized
efriedma added inline comments.
Comment at: lib/Basic/TargetInfo.cpp:229
switch (BitWidth) {
- case 96:
+ case 80:
if (&getLongDoubleFormat() == &llvm::APFloat::x87DoubleExtended)
ddcc wrote:
> bruno wrote:
> > The change makes sense but I believe there
spyffe added a comment.
I only have a stylistic nit to add to Aleksei's comments.
Comment at: lib/AST/ASTImporter.cpp:6492
+ UnresolvedSet<8> ToDecls;
+ for (UnresolvedLookupExpr::decls_iterator S = E->decls_begin(),
+F = E->decls_e
bettinson added a comment.
ping
https://reviews.llvm.org/D26800
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
ddcc added inline comments.
Comment at: lib/Basic/TargetInfo.cpp:229
switch (BitWidth) {
- case 96:
+ case 80:
if (&getLongDoubleFormat() == &llvm::APFloat::x87DoubleExtended)
bruno wrote:
> The change makes sense but I believe there's some historical r
spyffe requested changes to this revision.
spyffe added a comment.
This revision now requires changes to proceed.
There are several missing imports here, as well as a few minor nits.
If the unit test cases aren't catching these, I'm a little concerned. We
should be catching this.
Also we should
mehdi_amini added inline comments.
Comment at: lib/Sema/AnalysisBasedWarnings.cpp:530
+ // Don't need to mark Objective-C methods or blocks since the undefined
+ // behaviour optimization isn't used for them.
+}
Quuxplusone wrote:
> This seems like a trap waiti
mclow.lists added a comment.
There are no uses of `_LIBCPP_UNROLL_LOOPS` in LLVM (other than the ones in
``.
Googling for `_LIBCPP_UNROLL_LOOPS` on github finds the ones in libc++, and no
others.
I think I'll just take it out, and see what happens.
https://reviews.llvm.org/D26991
_
pcc added inline comments.
Comment at: clang/lib/CodeGen/CGBuilder.h:126
// FIXME: these "default-aligned" APIs should be removed,
// but I don't feel like fixing all the builtin code right now.
llvm::StoreInst *CreateDefaultAlignedStore(llvm::Value *Val,
---
rjmccall added inline comments.
Comment at: clang/lib/CodeGen/CGBuilder.h:126
// FIXME: these "default-aligned" APIs should be removed,
// but I don't feel like fixing all the builtin code right now.
llvm::StoreInst *CreateDefaultAlignedStore(llvm::Value *Val,
--
eugenis closed this revision.
eugenis added a comment.
Committed in r286613
Repository:
rL LLVM
https://reviews.llvm.org/D25928
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288062: [Driver] Add unit tests for Distro detection
(authored by mgorny).
Changed prior to commit:
https://reviews.llvm.org/D25869?vs=78625&id=79444#toc
Repository:
rL LLVM
https://reviews.llvm.org
This revision was automatically updated to reflect the committed changes.
Closed by commit rL288060: [Driver] Refactor distro detection & classification
as a separate API (authored by mgorny).
Changed prior to commit:
https://reviews.llvm.org/D25949?vs=78462&id=79442#toc
Repository:
rL LLVM
Author: mgorny
Date: Mon Nov 28 15:11:22 2016
New Revision: 288062
URL: http://llvm.org/viewvc/llvm-project?rev=288062&view=rev
Log:
[Driver] Add unit tests for Distro detection
Add a set of unit tests for the distro detection code. The tests use an
in-memory virtual filesystems resembling releas
Author: mgorny
Date: Mon Nov 28 15:11:18 2016
New Revision: 288061
URL: http://llvm.org/viewvc/llvm-project?rev=288061&view=rev
Log:
[Driver] Fix recognizing newer OpenSUSE versions
Fix recognizing newer OpenSUSE versions that combine the two version
components into 'VERSION = x.y'. The check was
Author: mgorny
Date: Mon Nov 28 15:11:14 2016
New Revision: 288060
URL: http://llvm.org/viewvc/llvm-project?rev=288060&view=rev
Log:
[Driver] Refactor distro detection & classification as a separate API
Refactor the Distro enum along with helper functions into a full-fledged
Distro class, inspire
Quuxplusone added inline comments.
Comment at: lib/Sema/AnalysisBasedWarnings.cpp:530
+ // Don't need to mark Objective-C methods or blocks since the undefined
+ // behaviour optimization isn't used for them.
+}
This seems like a trap waiting to spring on someo
bruno added a comment.
Hi Alex, thanks for working on this
Comment at: lib/Parse/ParseObjc.cpp:2877
+if (GetLookAheadToken(1).is(tok::l_brace) &&
+ExprStatementTokLoc == AtLoc) {
char ch = Tok.getIdentifierInfo()->getNameStart()[0];
--
Author: rnk
Date: Mon Nov 28 14:52:19 2016
New Revision: 288059
URL: http://llvm.org/viewvc/llvm-project?rev=288059&view=rev
Log:
[MS] Mangle a unique ID into all MS inline asm labels
This solves PR23715 in a way that is compatible with LTO.
MSVC supports jumping to source-level labels and betwe
pcc added inline comments.
Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2195
LoadInst *Load =
-Builder.CreateDefaultAlignedLoad(IntToPtr, /*isVolatile=*/true);
+Builder.CreateAlignedLoad(IntTy, IntToPtr, CharUnits::fromQuantity(4));
+Load->setVolatile(true
pcc updated this revision to Diff 79436.
pcc marked an inline comment as done.
pcc added a comment.
- Address review comments
https://reviews.llvm.org/D27157
Files:
clang/lib/CodeGen/CGBuilder.h
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGObjCGNU.cpp
bruno added inline comments.
Comment at: lib/Basic/TargetInfo.cpp:229
switch (BitWidth) {
- case 96:
+ case 80:
if (&getLongDoubleFormat() == &llvm::APFloat::x87DoubleExtended)
The change makes sense but I believe there's some historical reason why this
sebpop added a comment.
@mclow.lists could you please have a last look at this patch: the change is for
a performance improvement (20% uplift on a proprietary benchmark), and all the
issues mentioned in the review have been addressed.
The existing synthetic benchmark shows an overall improvement
mehdi_amini added a comment.
In https://reviews.llvm.org/D27163#606744, @arphaman wrote:
> In https://reviews.llvm.org/D27163#606695, @mehdi_amini wrote:
>
> > What is the justification for a platform specific default change here?
>
>
> The flag itself is platform agnostic, however, the default v
sebpop added a comment.
The numbers are from an x86_64-linux machine: Intel(R) Core(TM) i7-4790K CPU @
4.00GHz
Overall the patch is a win on the synthetic benchmark.
We have also seen this in a proprietary benchmark where it accounted for about
10% speedup.
https://reviews.llvm.org/D27068
_
sebpop added a comment.
In https://reviews.llvm.org/D27068#606757, @mclow.lists wrote:
> Definitely want to see numbers.
master:
Benchmark Time CPU Iterations
---
BM_StringFindPhase1/10
sebpop added a comment.
In https://reviews.llvm.org/D26991#606764, @mclow.lists wrote:
> /me wonders what the perf difference when `_LIBCPP_UNROLL_LOOPS` is defined
> or not.
>
> I think this (`_LIBCPP_UNROLL_LOOPS`) falls squarely into Chandler's request
> that we complain to him when the com
On Mon, Nov 28, 2016 at 11:11 AM, Antonio Maiorano wrote:
>> It's built with the script in utils/release/build_llvm_package.bat
> which I run manually on my machine once every few weeks.
>
> Okay, that's good news. So the simplest path to success would be to require
> the user to either pass the p
vangyzen added a comment.
A unit test change in https://reviews.llvm.org/D26979 found this and will
continue to test it (on some OSes).
https://reviews.llvm.org/D27167
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cg
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.
LGTM. Thanks.
https://reviews.llvm.org/D26612
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mai
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.
LGTM.
https://reviews.llvm.org/D26611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/lis
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.
Other than the missing `assert`s, (which are not your fault, but I would
appreciate you fixing) this LGTM.
Comment at: test/std/containers/sequences/array/at.pass.
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.
LGTM.
https://reviews.llvm.org/D27093
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/lis
On Mon, Nov 28, 2016 at 10:46 AM, Antonio Maiorano wrote:
> Okay, I'll see if upgrading to the 2015 assemblies would allow the VSIX to
> keep working in older versions of VS.
>
> Still waiting on an answer to this question:
>
>> In either case, though, I must ask: how is the offical vsix that's
>>
Eugene.Zelenko added a comment.
It'll be worth to mention enhancement in Release Notes.
https://reviews.llvm.org/D27166
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
mclow.lists accepted this revision.
mclow.lists added a comment.
This revision is now accepted and ready to land.
This LGTM.
https://reviews.llvm.org/D27096
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailma
mclow.lists added inline comments.
Comment at: include/__string:213
-static inline int compare(const char_type* __s1, const char_type* __s2,
size_t __n) _NOEXCEPT
-{return __n == 0 ? 0 : memcmp(__s1, __s2, __n);}
-static inline size_t length(const char_type* __
mclow.lists added a comment.
__search is the only place where `_LIBCPP_UNROLL_LOOPS` is currently used.
https://reviews.llvm.org/D26991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
mclow.lists added a comment.
/me wonders what the perf difference when `_LIBCPP_UNROLL_LOOPS` is defined or
not.
I think this (`_LIBCPP_UNROLL_LOOPS`) falls squarely into Chandler's request
that we complain to him when the compiler generates sub-optimal code, instead
of doing things like manu
eugenis added a comment.
I think this is the right move together with https://reviews.llvm.org/D26796.
Android build system will need to support both names for some time, depending
on the toolchain version - looks doable. Technically, it can stick with the old
name forever.
https://reviews.llv
mclow.lists added a comment.
Definitely want to see numbers.
https://reviews.llvm.org/D27068
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
alexfh added a comment.
I'll try to get back to this code review soon. Sorry for the delay.
Repository:
rL LLVM
https://reviews.llvm.org/D26137
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo
joerg removed rL LLVM as the repository for this revision.
joerg updated this revision to Diff 79423.
joerg added a comment.
Use llvm::yaml::escape.
https://reviews.llvm.org/D27140
Files:
include/clang/Driver/Options.td
lib/Driver/Tools.cpp
Index: include/clang/Driver/Options.td
==
arphaman added a comment.
In https://reviews.llvm.org/D27163#606695, @mehdi_amini wrote:
> What is the justification for a platform specific default change here?
The flag itself is platform agnostic, however, the default value is different
on Darwin (-fno-strict-return). The reason for this di
sebpop added a comment.
Please also post the performance numbers from the added benchmarks with and
without the change to the lib.
Comment at: libcxx/benchmarks/string.bench.cpp:12
+// until the end of s1.
+static void BM_StringFindPhase1(benchmark::State& state) {
+ // Bench
mgorny added a comment.
In https://reviews.llvm.org/D26764#606638, @beanz wrote:
> Looping in @eugenis, who added i686 support in r218761.
>
> eugenis, since i686 is identical to i386 generating it as a separate target
> is undesirable. Can you help advise as to how we can better meet your needs
sebpop added a comment.
Let's also add a testcase and show the performance improvement.
https://reviews.llvm.org/D26991
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
On Fri, Nov 25, 2016 at 6:58 PM, Antonio Maiorano wrote:
> Ah, no, that's not what I meant. The required referenced assemblies are
> versions that are normally installed with VS 2010.
>
> The first time I worked on this, I had upgraded the referenced assemblies to
> the ones that ship with VS 2015
mehdi_amini added a comment.
What is the justification for a platform specific default change here?
Repository:
rL LLVM
https://reviews.llvm.org/D27163
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/
1 - 100 of 137 matches
Mail list logo