twoh created this revision.
This patch implements 4.3 of
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4220.pdf. If a raw string
contains a newline character, replace each newline character with the \n escape
code. Without this patch, included test case (macro_raw_string.cpp) results
co
malaperle accepted this revision.
malaperle added a comment.
Nice! I had a fix locally for the same purpose but this is much better!
https://reviews.llvm.org/D38939
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bi
mstorsjo added a comment.
In https://reviews.llvm.org/D39251#906110, @compnerd wrote:
> Whats the motivation for adding DWARF based unwinding on ARM? What
> environment is using this?
AFAIK NetBSD does.
And my actual target is for MinGW/ARM; it seemed to be less effort to make
libunwind wor
compnerd added a comment.
Whats the motivation for adding DWARF based unwinding on ARM? What environment
is using this?
Comment at: src/Registers.hpp:1342
}
+ static int lastDwarfRegNum() { return 287; }
Can we not use `_LIBUNWIND_HIGHEST_DWARF_REGISTE
Author: compnerd
Date: Tue Oct 24 20:58:15 2017
New Revision: 316545
URL: http://llvm.org/viewvc/llvm-project?rev=316545&view=rev
Log:
CodeGen: fix a case of incorrect checks for ivars
Ensure that we check the ivar containing decl for the DLL storage
attribute rather than the ivar itself as the d
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316542: [CMake] Build host builtins in Fuchsia toolchain
even on Darwin (authored by phosek).
Changed prior to commit:
https://reviews.llvm.org/D39273?vs=120165&id=120179#toc
Repository:
rL LLVM
htt
Author: phosek
Date: Tue Oct 24 19:35:22 2017
New Revision: 316542
URL: http://llvm.org/viewvc/llvm-project?rev=316542&view=rev
Log:
[CMake] Build host builtins in Fuchsia toolchain even on Darwin
This is nedeeded for the toolchain to be actually usable as a host
toolchain on Darwin.
Differentia
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316541: [CMake] Include clang-refactor in Fuchsia toolchain
(authored by phosek).
Changed prior to commit:
https://reviews.llvm.org/D39270?vs=120163&id=120178#toc
Repository:
rL LLVM
https://reviews
Author: phosek
Date: Tue Oct 24 19:31:38 2017
New Revision: 316541
URL: http://llvm.org/viewvc/llvm-project?rev=316541&view=rev
Log:
[CMake] Include clang-refactor in Fuchsia toolchain
This includes the clang-refactor in the toolchain distribution.
Differential Revision: https://reviews.llvm.org
mcgrathr accepted this revision.
mcgrathr added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rL LLVM
https://reviews.llvm.org/D39273
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi
phosek created this revision.
phosek added a project: clang.
Herald added a subscriber: mgorny.
This is needed for the toolchain to be actually usable as a host
toolchain on Darwin.
Repository:
rL LLVM
https://reviews.llvm.org/D39273
Files:
cmake/caches/Fuchsia-stage2.cmake
Index: cmake/
mcgrathr accepted this revision.
mcgrathr added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rL LLVM
https://reviews.llvm.org/D39270
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi
Author: phosek
Date: Tue Oct 24 18:11:27 2017
New Revision: 316540
URL: http://llvm.org/viewvc/llvm-project?rev=316540&view=rev
Log:
[clang-refactor] Use add_clang_tool CMake template
This allows including clang-refactor in LLVM_DISTRIBUTION_COMPONENTS
to build clang-refactor as part of the toolc
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316540: [clang-refactor] Use add_clang_tool CMake template
(authored by phosek).
Changed prior to commit:
https://reviews.llvm.org/D39266?vs=120155&id=120164#toc
Repository:
rL LLVM
https://reviews.
phosek created this revision.
phosek added a project: clang.
Herald added a subscriber: mgorny.
This includes the clang-refactor in the toolchain distribution.
Repository:
rL LLVM
https://reviews.llvm.org/D39270
Files:
cmake/caches/Fuchsia-stage2.cmake
Index: cmake/caches/Fuchsia-stage2.
george.karpenkov created this revision.
Herald added subscribers: szepet, xazax.hun.
Contrary to the deleted comment, in most cases CmpRuns.py produces a fairly
small amount of output, which is useful to see straight away to see what has
changed when executing the integration tests.
https://re
arphaman added a comment.
In https://reviews.llvm.org/D36790#843450, @arphaman wrote:
> @rjmccall Do you think that the rules for the return types in overridden
> methods that return `instancetype` should be strengthened first? For example,
> if we have the following code:
>
> @interface Unre
arphaman updated this revision to Diff 120157.
arphaman retitled this revision from "[ObjC] Messages to 'self' in class
methods should use class method dispatch to avoid multiple method ambiguities"
to "[ObjC] Messages to 'self' in class methods that return 'instancetype'
should use the pointer
arphaman accepted this revision.
arphaman added a comment.
This revision is now accepted and ready to land.
Thanks!
Repository:
rL LLVM
https://reviews.llvm.org/D39266
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/
phosek created this revision.
phosek added a project: clang.
Herald added a subscriber: mgorny.
This allows including clang-refactor in LLVM_DISTRIBUTION_COMPONENTS
to build clang-refactor as part of the toolchain distribution.
Repository:
rL LLVM
https://reviews.llvm.org/D39266
Files:
too
Author: george.karpenkov
Date: Tue Oct 24 17:03:45 2017
New Revision: 316539
URL: http://llvm.org/viewvc/llvm-project?rev=316539&view=rev
Log:
[Analyzer] Remove spaces inside comments mentioning the parameter name,
to aid clang-tidy comprehension.
Requested by @alexfh in https://reviews.llvm.org/
Author: george.karpenkov
Date: Tue Oct 24 17:03:45 2017
New Revision: 316538
URL: http://llvm.org/viewvc/llvm-project?rev=316538&view=rev
Log:
[Analyzer] Remove unnecessary semicolon in analyzer tests.
Modified:
cfe/trunk/test/Analysis/call_once.cpp
Modified: cfe/trunk/test/Analysis/call_onc
george.karpenkov added inline comments.
Comment at: cfe/trunk/lib/Analysis/BodyFarm.cpp:139
-DeclRefExpr *ASTMaker::makeDeclRefExpr(const VarDecl *D,
- bool RefersToEnclosingVariableOrCapture,
- bool Ge
Author: george.karpenkov
Date: Tue Oct 24 16:53:19 2017
New Revision: 316536
URL: http://llvm.org/viewvc/llvm-project?rev=316536&view=rev
Log:
[Analyzer] Store BodyFarm in std::unique_ptr
Differential Revision: https://reviews.llvm.org/D39220
Modified:
cfe/trunk/include/clang/Analysis/Analys
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316536: [Analyzer] Store BodyFarm in std::unique_ptr
(authored by george.karpenkov).
Changed prior to commit:
https://reviews.llvm.org/D39220?vs=120109&id=120151#toc
Repository:
rL LLVM
https://revi
Author: george.karpenkov
Date: Tue Oct 24 16:52:48 2017
New Revision: 316535
URL: http://llvm.org/viewvc/llvm-project?rev=316535&view=rev
Log:
[Analyzer] [Tests] Minor refactor of testing infrastructure:
Move utilities functions into a separate file to make comprehension
easier.
Added:
cfe/t
Author: george.karpenkov
Date: Tue Oct 24 16:52:46 2017
New Revision: 316534
URL: http://llvm.org/viewvc/llvm-project?rev=316534&view=rev
Log:
[Analyzer] [Tests] Remove temporary fields from generated reference results.
Pointer to HTML diagnostics is removed (as it is not stored) as well as
the v
george.karpenkov added inline comments.
Comment at: include/clang/Analysis/AnalysisDeclContext.h:424
/// methods during the analysis.
- BodyFarm *BdyFrm = nullptr;
+ std::unique_ptr BdyFrm;
alexfh wrote:
> BdyFrm is somewhat cryptic. Maybe Farm, Bodies or
Author: ahatanak
Date: Tue Oct 24 16:38:14 2017
New Revision: 316531
URL: http://llvm.org/viewvc/llvm-project?rev=316531&view=rev
Log:
[Sema][ObjC] Look for either objc_bridge or objc_bridge_mutable when
determining whether a RecordDecl is CFError.
CFErrorRef used to be declared with "objc_bridge
efriedma added a comment.
I think you're understanding the semantics correctly.
For r265521, look again at the implementation of
llvm::checkUnaryFloatSignature; if "I.onlyReadsMemory()" is true, we somehow
proved the call doesn't set errno (mostly likely because we know something
about the tar
alexfh added inline comments.
Comment at: include/clang/Analysis/AnalysisDeclContext.h:424
/// methods during the analysis.
- BodyFarm *BdyFrm = nullptr;
+ std::unique_ptr BdyFrm;
BdyFrm is somewhat cryptic. Maybe Farm, Bodies or something else that is no
dcoughlin accepted this revision.
dcoughlin added a comment.
LGTM.
https://reviews.llvm.org/D39220
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: erichkeane
Date: Tue Oct 24 16:12:01 2017
New Revision: 316528
URL: http://llvm.org/viewvc/llvm-project?rev=316528&view=rev
Log:
Correct behavior of fastcall when default CC is set.
Fastcall doesn't support variadic function calls, so
setting the default calling convention to Fastcall wou
george.karpenkov added inline comments.
Comment at: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp:607
+AnalysisDeclContextManager::~AnalysisDeclContextManager() {
+ if (!BdyFrm)
+delete BdyFrm;
alexfh wrote:
> This is an almost guaranteed memory leak. I thi
alexfh added inline comments.
Comment at: cfe/trunk/test/Analysis/call_once.cpp:298
+ param = 42;
+};
+void test_implicit_funcptr() {
Any reason for the stray semicolon here?
Repository:
rL LLVM
https://reviews.llvm.org/D39201
___
alexfh added inline comments.
Comment at: cfe/trunk/lib/Analysis/BodyFarm.cpp:366
+M.makeLvalueToRvalue(D->getParamDecl(i),
+ /* RefersToEnclosingVariableOrCapture= */ false));
Remove the spaces inside the comment. `/*ParamNa
alexfh added inline comments.
Comment at: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp:607
+AnalysisDeclContextManager::~AnalysisDeclContextManager() {
+ if (!BdyFrm)
+delete BdyFrm;
This is an almost guaranteed memory leak. I think, you meant `if (BdyFrm)
Author: george.karpenkov
Date: Tue Oct 24 15:24:13 2017
New Revision: 316522
URL: http://llvm.org/viewvc/llvm-project?rev=316522&view=rev
Log:
[Analyzer] Fix bug in testing scripts, which always marked result as failure.
Modified:
cfe/trunk/utils/analyzer/SATestBuild.py
Modified: cfe/trunk/u
Author: erichkeane
Date: Tue Oct 24 15:00:25 2017
New Revision: 316521
URL: http://llvm.org/viewvc/llvm-project?rev=316521&view=rev
Log:
Replaced unicode characters with ASCII, as introduced in r316518.
Modified:
cfe/trunk/lib/AST/Type.cpp
Modified: cfe/trunk/lib/AST/Type.cpp
URL:
http://ll
Yikes! Thanks for pointing this out, fixing it now.
From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Tuesday, October 24, 2017 2:55 PM
To: Keane, Erich
Cc: cfe-commits
Subject: Re: r316518 - mplement __has_unique_object_representations
On Tue, Oct 24, 2017 at 2:31 PM, Erich Keane
On Tue, Oct 24, 2017 at 2:31 PM, Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: erichkeane
> Date: Tue Oct 24 14:31:50 2017
> New Revision: 316518
>
> URL: http://llvm.org/viewvc/llvm-project?rev=316518&view=rev
> Log:
> mplement __has_unique_object_representations
>
>
frutiger added inline comments.
Comment at: test/Index/c-index-getCursor-test.m:167
// CHECK: [57:1 - 57:10] FunctionDecl=f:57:6 (Definition)
-// CHECK: [58:4 - 58:8] VarDecl=my_var:58:8 (Definition)
+// CHECK: [58:4 - 58:8] VarDecl=my_var:2:1 (Definition)
// CHECK: [58:8 - 58:
eugenis added a comment.
ping
https://reviews.llvm.org/D38430
___
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 rL316518: mplement __has_unique_object_representations
(authored by erichkeane).
Changed prior to commit:
https://reviews.llvm.org/D39064?vs=120132&id=120137#toc
Repository:
rL LLVM
https://reviews.ll
Author: erichkeane
Date: Tue Oct 24 14:31:50 2017
New Revision: 316518
URL: http://llvm.org/viewvc/llvm-project?rev=316518&view=rev
Log:
mplement __has_unique_object_representations
A helper builtin to facilitate implementing the
std::has_unique_object_representations type trait.
Requested here:
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm, thanks!
https://reviews.llvm.org/D39064
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cf
On Tue, Oct 24, 2017 at 3:00 PM, Hans Wennborg wrote:
> On Mon, Oct 23, 2017 at 2:02 PM, Roman Lebedev wrote:
>> On Mon, Oct 23, 2017 at 2:13 PM, Hans Wennborg wrote:
>> Hi.
>>
>>> This seems to have had the side effect of introducing a new warning in
>>> Chromium builds:
>>>
>>> ../../third_par
Author: lebedevri
Date: Tue Oct 24 14:05:43 2017
New Revision: 316500
URL: http://llvm.org/viewvc/llvm-project?rev=316500&view=rev
Log:
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC]
rL316268 / D39122 has fixed PR35009, and now when in C,
these three(?) diagnostics prope
jklaehn added a comment.
ping :)
https://reviews.llvm.org/D35181
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jklaehn added a comment.
ping :)
https://reviews.llvm.org/D36952
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
erichkeane updated this revision to Diff 120132.
erichkeane added a comment.
Adding tests for excluding dynamic types.
https://reviews.llvm.org/D39064
Files:
include/clang/AST/Type.h
include/clang/Basic/TokenKinds.def
include/clang/Basic/TypeTraits.h
lib/AST/Type.cpp
lib/Parse/ParseEx
erichkeane added inline comments.
Comment at: lib/AST/Type.cpp:2212-2213
+for (const auto Base : ClassDecl->bases()) {
+ if (Base.isVirtual())
+return false;
+
rnk wrote:
> OK, I guess vbases don't have a unique representation. :) What about vtab
arphaman added inline comments.
Comment at: include/clang/Tooling/Refactoring/RefactoringActionRule.h:58
+ /// Returns the editor command that's was bound to this rule.
+ virtual const EditorCommand *getEditorCommand() { return nullptr; }
};
ioeric wrote:
> ar
tmsriram added a comment.
In https://reviews.llvm.org/D39079#905519, @joerg wrote:
> In https://reviews.llvm.org/D39079#905468, @rnk wrote:
>
> > In https://reviews.llvm.org/D39079#905454, @joerg wrote:
> >
> > > It also increases the pressure on the branch predictor, so it is not
> > > really b
jklaehn added inline comments.
Comment at: test/Index/annotate-tokens.c:226
// CHECK-RANGE2: Punctuation: "." [55:5 - 55:6] UnexposedExpr=
-// CHECK-RANGE2: Identifier: "z" [55:6 - 55:7] MemberRef=z:52:1
+// CHECK-RANGE2: Identifier: "z" [55:6 - 55:7] MemberRef=z:41:9
// CHECK-
arphaman updated this revision to Diff 120129.
arphaman marked an inline comment as done.
arphaman added a comment.
Fix comment nit.
Repository:
rL LLVM
https://reviews.llvm.org/D38985
Files:
include/clang/Tooling/Refactoring/RefactoringActionRule.h
include/clang/Tooling/Refactoring/Refa
arphaman updated this revision to Diff 120128.
arphaman added a comment.
Avoid using a separate EditorCommand class.
Repository:
rL LLVM
https://reviews.llvm.org/D38985
Files:
include/clang/Tooling/Refactoring/RefactoringActionRule.h
include/clang/Tooling/Refactoring/RefactoringActionRul
probinson added a comment.
Have you tried this change against the GDB and LLDB test suites? If they have
failures then we should think about whether those tests are over-specific or
whether we should put this under a tuning option.
https://reviews.llvm.org/D39239
__
mibintc added a comment.
In https://reviews.llvm.org/D34158#905596, @jyknight wrote:
> I'd still _very_ much like a solution that is acceptable for all libc to use,
> and have that on by default.
>
> However, I guess this is fine.
>
> Only concern I have is that it seems odd that so many test-ca
lichray accepted this revision.
lichray added a comment.
This revision is now accepted and ready to land.
LGTM
https://reviews.llvm.org/D39220
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
Author: abataev
Date: Tue Oct 24 12:52:31 2017
New Revision: 316488
URL: http://llvm.org/viewvc/llvm-project?rev=316488&view=rev
Log:
[OPENMP] Fix PR35013: Fix passing VLAs captures to outlined functions.
Fixed passing of VLAs and variably-modified types to outlined functions.
Synchronized passin
jyknight added a comment.
I'd still _very_ much like a solution that is acceptable for all libc to use,
and have that on by default.
However, I guess this is fine.
Only concern I have is that it seems odd that so many test-cases needed to be
changed. What fails without those test changes?
ht
rnk added inline comments.
Comment at: lib/AST/Type.cpp:2212-2213
+for (const auto Base : ClassDecl->bases()) {
+ if (Base.isVirtual())
+return false;
+
OK, I guess vbases don't have a unique representation. :) What about vtable
slots? Should we
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316484: CodeGen: Fix missing debug loc due to alloca
(authored by yaxunl).
Changed prior to commit:
https://reviews.llvm.org/D39069?vs=120076&id=120115#toc
Repository:
rL LLVM
https://reviews.llvm.o
Author: yaxunl
Date: Tue Oct 24 12:14:43 2017
New Revision: 316484
URL: http://llvm.org/viewvc/llvm-project?rev=316484&view=rev
Log:
CodeGen: Fix missing debug loc due to alloca
Builder save/restores insertion pointer when emitting addr space cast
for alloca, but does not save/restore debug loc,
sbc100 updated this revision to Diff 120111.
sbc100 added a comment.
- remove debugging
- git squash commit for startup_libs.
- update test expectations
https://reviews.llvm.org/D39218
Files:
lib/Driver/ToolChain.cpp
lib/Driver/ToolChains/CommonArgs.cpp
lib/Driver/ToolChains/WebAssembly.c
mstorsjo created this revision.
Herald added subscribers: kristof.beyls, aprantl, aemerson.
The previous definition of _LIBUNWIND_HIGHEST_DWARF_REGISTER seems to be a copy
of the ARM64 value (introduced in SVN r276128); since the code actually hasn't
compiled properly for arm in dwarf mode befor
george.karpenkov updated this revision to Diff 120109.
https://reviews.llvm.org/D39220
Files:
include/clang/Analysis/AnalysisDeclContext.h
lib/Analysis/AnalysisDeclContext.cpp
Index: lib/Analysis/AnalysisDeclContext.cpp
===
---
joerg added a comment.
In https://reviews.llvm.org/D39079#905468, @rnk wrote:
> In https://reviews.llvm.org/D39079#905454, @joerg wrote:
>
> > It also increases the pressure on the branch predictor, so it is not really
> > black and white.
>
>
> I don't understand this objection. I'm assuming th
erichkeane updated this revision to Diff 120106.
erichkeane added a comment.
Based on @rnk s comments, I discovered that base-class handling is more
difficult than I suspected! I added a couple more tests and am properly
handling base classes.
https://reviews.llvm.org/D39064
Files:
include
arphaman added a comment.
You
In https://reviews.llvm.org/D38985#901152, @sammccall wrote:
> Hi Alex! I'm working on clangd, but am pretty new to the project, so forgive
> some naive questions.
>
> I'm a bit unclear at a high level what the new abstractions in this patch
> add, in terms of wir
tmsriram added a comment.
In https://reviews.llvm.org/D39079#905468, @rnk wrote:
> In https://reviews.llvm.org/D39079#905454, @joerg wrote:
>
> > It also increases the pressure on the branch predictor, so it is not really
> > black and white.
>
>
> I don't understand this objection. I'm assuming
rnk added a comment.
In https://reviews.llvm.org/D39079#905454, @joerg wrote:
> It also increases the pressure on the branch predictor, so it is not really
> black and white.
I don't understand this objection. I'm assuming that the PLT stub is an
indirect jump through the PLTGOT, not a hotpat
tmsriram added a comment.
In https://reviews.llvm.org/D39079#905454, @joerg wrote:
> In https://reviews.llvm.org/D39079#905396, @rnk wrote:
>
> > In https://reviews.llvm.org/D39079#905372, @joerg wrote:
> >
> > > Why again is this a good idea?
> >
> >
> > It saves the direct jump to the PLT, redu
tmsriram added a comment.
In https://reviews.llvm.org/D39079#905423, @rnk wrote:
> In https://reviews.llvm.org/D39079#905395, @joerg wrote:
>
> > Let me phrase it differently. What is this patch (and the matching backend
> > PR) supposed to achieve? There are effectively two ways to get rid of P
joerg added a comment.
In https://reviews.llvm.org/D39079#905396, @rnk wrote:
> In https://reviews.llvm.org/D39079#905372, @joerg wrote:
>
> > Why again is this a good idea?
>
>
> It saves the direct jump to the PLT, reducing icache pressure, which is a
> major cost in some workloads.
It also
hfinkel added a comment.
In https://reviews.llvm.org/D39138#905445, @rjmccall wrote:
> In https://reviews.llvm.org/D39138#905184, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D39138#904747, @rjmccall wrote:
> >
> > > Okay, if this is just for your own checking, I'd rather not take it.
> >
rjmccall added a comment.
In https://reviews.llvm.org/D39138#905184, @hfinkel wrote:
> In https://reviews.llvm.org/D39138#904747, @rjmccall wrote:
>
> > Okay, if this is just for your own checking, I'd rather not take it. It's
> > not a significant compile-time cost, but there's no reason to pa
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
Okay, LGTM.
https://reviews.llvm.org/D39069
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/lis
rnk added a comment.
Can you remind me why `NamedDecl::printQualifiedName` is not appropriate for
your needs?
https://reviews.llvm.org/D39224
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe
hfinkel added a comment.
> what is breaking the ELF interposition rules
Frankly, in retrospect, ELF's interposition rules (or at least the defaults for
those rules), seem suboptimal on several fronts. While breaking them has some
unfortunate consistency implications, I don't consider breaking t
rnk added a comment.
In https://reviews.llvm.org/D39079#905395, @joerg wrote:
> Let me phrase it differently. What is this patch (and the matching backend
> PR) supposed to achieve? There are effectively two ways to get rid of PLT
> entries:
> (1) Bind references locally. This is effectively w
On Tue, Oct 24, 2017 at 10:25 AM, Joerg Sonnenberger via Phabricator
wrote:
> joerg added a comment.
>
> Let me phrase it differently. What is this patch (and the matching backend
> PR) supposed to achieve? There are effectively two ways to get rid of PLT
> entries:
> (1) Bind references locally
rnk added a comment.
In https://reviews.llvm.org/D39079#905372, @joerg wrote:
> Why again is this a good idea?
It saves the direct jump to the PLT, reducing icache pressure, which is a major
cost in some workloads.
> This is an even worse hack than -Bsymbolic,
Personally, I would like to bui
joerg added a comment.
Let me phrase it differently. What is this patch (and the matching backend PR)
supposed to achieve? There are effectively two ways to get rid of PLT entries:
(1) Bind references locally. This is effectively what -Bsymbolic does and what
is breaking the ELF interposition ru
dschuff accepted this revision.
dschuff added inline comments.
This revision is now accepted and ready to land.
Comment at: lib/Driver/ToolChain.cpp:318
+ else
+OSLibName = getOS();
llvm::sys::path::append(Path, "lib", OSLibName);
sbc100 wrote:
> dschuff
hfinkel added a comment.
In https://reviews.llvm.org/D39079#905371, @tmsriram wrote:
> In https://reviews.llvm.org/D39079#905353, @hfinkel wrote:
>
> > Noting that, as @vit9696 pointed out in https://reviews.llvm.org/D38554,
> > this does not suppress uses of the PLT that occur from
> > backen
Author: arphaman
Date: Tue Oct 24 10:23:53 2017
New Revision: 316467
URL: http://llvm.org/viewvc/llvm-project?rev=316467&view=rev
Log:
Add missing clangRewrite lib dependency for clangToolingRefactor
Modified:
cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
Modified: cfe/trunk/lib/Tooling/R
arphaman added inline comments.
Comment at: include/clang/Basic/DiagnosticRefactoringKinds.td:24
+ "not overlap with the AST nodes of interest">;
+
+def err_refactor_code_outside_of_function : Error<"the selected code is not a "
ioeric wrote:
> nit: was this new
This revision was automatically updated to reflect the committed changes.
arphaman marked an inline comment as done.
Closed by commit rL316465: [refactor] Initial outline of implementation of
"extract function" refactoring (authored by arphaman).
Changed prior to commit:
https://reviews.llvm.or
Author: arphaman
Date: Tue Oct 24 10:18:45 2017
New Revision: 316465
URL: http://llvm.org/viewvc/llvm-project?rev=316465&view=rev
Log:
[refactor] Initial outline of implementation of "extract function" refactoring
This commit adds an initial, skeleton outline of the "extract function"
refactoring
tmsriram added a comment.
In https://reviews.llvm.org/D39079#905372, @joerg wrote:
> Why again is this a good idea? This is an even worse hack than -Bsymbolic,
> the latter at least is visible in ELF header without code inspection. This is
> breaking core premises of ELF.
Could you elaborate
tmsriram added a comment.
In https://reviews.llvm.org/D39079#905353, @hfinkel wrote:
> Noting that, as @vit9696 pointed out in https://reviews.llvm.org/D38554,
> this does not suppress uses of the PLT that occur from
> backend/optimizer-generated functions (e.g., calls into compiler-rt and
>
joerg added a comment.
Why again is this a good idea? This is an even worse hack than -Bsymbolic, the
latter at least is visible in ELF header without code inspection. This is
breaking core premises of ELF.
https://reviews.llvm.org/D39079
___
cfe-
sbc100 added inline comments.
Comment at: lib/Driver/ToolChain.cpp:318
+ else
+OSLibName = getOS();
llvm::sys::path::append(Path, "lib", OSLibName);
dschuff wrote:
> Is this logic intended to replace what was removed from CommonArgs.cpp?
> Should there b
spatel added a comment.
Working my way through the stack: does the sqrt LangRef change mean we can
revert https://reviews.llvm.org/rL265521? What allows us to transform any of
those libm calls that set errno to vectors in the first place?
I'm even more confused than usual, but if I can find a w
hfinkel added subscribers: vit9696, hfinkel.
hfinkel added a comment.
Noting that, as @vit9696 pointed out in https://reviews.llvm.org/D38554, this
does not suppress uses of the PLT that occur from backend/optimizer-generated
functions (e.g., calls into compiler-rt and similar).
https://revie
doug.gregor added a comment.
Yes, I think it's reasonable to treat instancetype as an inherited requirement.
I guess the only exception would be if we had some notion of final classes or
methods in Objective-C, in which case they'd be able to return a concrete type.
Repository:
rL LLVM
http
Author: arphaman
Date: Tue Oct 24 09:39:37 2017
New Revision: 316458
URL: http://llvm.org/viewvc/llvm-project?rev=316458&view=rev
Log:
[code completion] Complete ObjC methods in @implementation without leading
'-'/'+' prefix
rdar://12040840
Modified:
cfe/trunk/include/clang/Sema/Sema.h
c
Author: marshall
Date: Tue Oct 24 09:30:06 2017
New Revision: 316456
URL: http://llvm.org/viewvc/llvm-project?rev=316456&view=rev
Log:
Mark string_view's constructor from (ptr,len) as noexcept (an extension).
Update the tests to check this (and other noexcept bits
Modified:
libcxx/trunk/incl
1 - 100 of 147 matches
Mail list logo
