avt77 added inline comments.
Comment at: lib/Basic/FrontendTiming.cpp:18
+
+bool FrontendTimesIsEnabled = false;
+
efriedma wrote:
> Why is this in lib/Basic, when the declaration is in include/clang/Frontend/?
Because this library is being linked to all others a
avt77 added a comment.
In https://reviews.llvm.org/D43578#1067768, @rsmith wrote:
> Last time I looked at doing this, I found that LLVM's timer infrastructure
> was fundamentally unsuitable for adding timers like these to Clang.
Thank you for this answer. As I understand we should close both t
Hi Richard,
On Sat, Apr 14, 2018 at 1:53 AM, Richard Smith - zygoloid via
Phabricator via cfe-commits wrote:
> rsmith added a comment.
>
> So I don't think this patch is reasonable for that reason. I'm also not sure
> whether this, as is, is addressing a pressing use case -- for Clang
> develop
kimgr added a comment.
Heh, my e-mail response was eaten along the way. Continued here:
On Sat, Apr 14, 2018 at 1:53 AM, Richard Smith - zygoloid via
Phabricator via cfe-commits wrote:
> rsmith added a comment.
>
> So I don't think this patch is reasonable for that reason. I'm also not sure
>
rjmccall added inline comments.
Comment at: lib/Frontend/CompilerInvocation.cpp:2109
+ Opts.HIP = true;
+ }
+
yaxunl wrote:
> rjmccall wrote:
> > Why is this done here? We infer the language mode from the input kind
> > somewhere else.
> It is usually don
MTC added a comment.
In https://reviews.llvm.org/D45491#1067852, @NoQ wrote:
> Yeah, i think this makes sense, thanks! It feels a bit weird that we have to
> add it as an exception - i wonder if there are other exceptions that we need
> to make. Widening over the stack memory space should be a
On Sat, 14 Apr 2018, 04:22 Richard Trieu via cfe-commits, <
cfe-commits@lists.llvm.org> wrote:
> I was tracking down a similar issue to the lldb issue before noticing the
> change was reverted. The bad change that lead to it is:
>
> // Load pending declaration chains.
> -for (unsigned I
That would be a nice outcome of all the "run-tools-on-llvm" changes if any
problems were filed as bugs on the tools. We have a number of them filed on
iwyu, and they make for nice, concrete bugs to troubleshoot even if we
don't always know how to fix them.
For this specific clang-tidy issue, do yo
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
LGTM.
https://reviews.llvm.org/D45489
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.
If so, LGTM.
Comment at: lib/Frontend/InitPreprocessor.cpp:473
+ Builder.defineMacro("__HIP_DEVICE_COMPILE__");
+ }
}
I assume these names are def
jklaehn added a comment.
friendly ping? :)
Repository:
rC Clang
https://reviews.llvm.org/D35181
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.
LGTM aside from a few small nits.
Comment at: include/clang/Basic/IdentifierTable.h:471
+ /// \brief Create the identifier table.
+ IdentifierTable(Identifier
rsmith added a comment.
Thanks! This is looking pretty close.
Comment at: include/clang/AST/ComparisonCategories.h:78
+public:
+ /// \brief Wether Sema has fully checked the type and result values for this
+ /// comparison category types before.
Typo "Wethe
rsmith added inline comments.
Comment at: lib/Sema/SemaExpr.cpp:9928
+// result is of type std::strong_equality
+if (CompositeTy->isFunctionPointerType() ||
+CompositeTy->isMemberPointerType() || CompositeTy->isNullPtrType())
Please add a FIXME he
rsmith added a comment.
In https://reviews.llvm.org/D43578#1067891, @kimgr wrote:
> I disagreed up until the last paragraph :)
Can you say which things you disagree with? There seem to be two important
facts here:
1. LLVM's timing infrastructure cannot correctly report timings when one
funct
On Sat, 14 Apr 2018, 14:16 Kim Gräsman, wrote:
> That would be a nice outcome of all the "run-tools-on-llvm" changes if any
> problems were filed as bugs on the tools. We have a number of them filed on
> iwyu, and they make for nice, concrete bugs to troubleshoot even if we
> don't always know ho
zahiraam added a comment.
In https://reviews.llvm.org/D43576#1016295, @majnemer wrote:
> We should really, really avoid making this sort of change without first
> trying to desugar uuidof into a reference to a variable. That would solve a
> ton of problems, problems like this one.
Not sure I
rsmith added a comment.
In https://reviews.llvm.org/D43578#1067879, @avt77 wrote:
> In https://reviews.llvm.org/D43578#1067768, @rsmith wrote:
>
> > Last time I looked at doing this, I found that LLVM's timer infrastructure
> > was fundamentally unsuitable for adding timers like these to Clang.
zahiraam updated this revision to Diff 142516.
https://reviews.llvm.org/D43576
Files:
include/clang/AST/Decl.h
include/clang/AST/RecursiveASTVisitor.h
include/clang/Basic/Attr.td
include/clang/Basic/DeclNodes.td
include/clang/Sema/AttributeList.h
include/clang/Sema/Sema.h
lib/AST/De
rsmith added inline comments.
Comment at: include/clang/Sema/AttributeList.h:601
+ sizeof(AttributeList)
+ + (sizeof(DeclSpecUuidDecl) + sizeof(void *) + sizeof(ArgsUnion) - 1)
/ sizeof(void*) * sizeof(void*)
You're not storing a `DeclSpecUuidD
kimgr added a comment.
In https://reviews.llvm.org/D43578#1067974, @rsmith wrote:
> In https://reviews.llvm.org/D43578#1067891, @kimgr wrote:
>
> > I disagreed up until the last paragraph :)
>
>
> Can you say which things you disagree with? There seem to be two important
> facts here:
>
> 1. LLV
Author: ibiryukov
Date: Sat Apr 14 09:27:35 2018
New Revision: 330087
URL: http://llvm.org/viewvc/llvm-project?rev=330087&view=rev
Log:
[clangd] Fix label and snippet for funcs in the index
This is a follow-up to r330004 to fix functions with required template args,
e.g. std::make_shared.
Modifi
compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.
Sorry for the delay, didn't see the changes earlier.
Comment at: clang/lib/CodeGen/CGAtomic.cpp:883
if (UseLibcall) {
+CGM.getDiags().Report(E->getLocStart(), diag
JonasToth updated this revision to Diff 142521.
JonasToth added a comment.
- [Feature] implement array and method access
- [Feature] finalize value semantic
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D45444
Files:
clang-tidy/cppcoreguidelines/CMakeLists.txt
clang-tidy/cp
JonasToth updated this revision to Diff 142526.
JonasToth added a comment.
- [Feature] start working on handle semantic
Repository:
rCTE Clang Tools Extra
https://reviews.llvm.org/D45444
Files:
clang-tidy/cppcoreguidelines/CMakeLists.txt
clang-tidy/cppcoreguidelines/ConstCheck.cpp
clan
compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.
I definitely like the clean up. Not sure I understand the motivation for the
`__libcpp_relaxed_store`, but I suppose thats because its a copy from libc++
where it may be more useful.
Re
compnerd added a comment.
Snipping bits from `va_defs.h`:
#elif defined _M_ARM64
void __cdecl __va_start(va_list*, ...);
#define __crt_va_start_a(ap,v) ((void)(__va_start(&ap, _ADDRESSOF(v),
_SLOTSIZEOF(v), __alignof(v), _ADDRESSOF(v
...
#elif defined _M_X64
compnerd added a comment.
I'm not sure I understand this. The proper location for libc++ on the darwin
layout is in the SDK, not relative to the driver. The default behaviour is
similar to cross-compiling, and with a (derived) SDK. This definitely needs to
be reviewed by @dexonsmith
Reposi
EricWF marked 24 inline comments as done.
EricWF added inline comments.
Comment at: lib/AST/ExprConstant.cpp:3784
+static bool EvaluateVarDecl(EvalInfo &Info, const VarDecl *VD,
+APValue *Dest = nullptr) {
// We don't need to evaluate the initialize
EricWF marked 4 inline comments as done.
EricWF added inline comments.
Comment at: lib/Sema/SemaExpr.cpp:9928
+// result is of type std::strong_equality
+if (CompositeTy->isFunctionPointerType() ||
+CompositeTy->isMemberPointerType() || CompositeTy->isNullPtrType(
EricWF added inline comments.
Comment at: lib/Sema/SemaExpr.cpp:9928
+// result is of type std::strong_equality
+if (CompositeTy->isFunctionPointerType() ||
+CompositeTy->isMemberPointerType() || CompositeTy->isNullPtrType())
EricWF wrote:
> rsmit
EricWF marked 3 inline comments as done.
EricWF added inline comments.
Comment at: lib/Sema/SemaExpr.cpp:9816
+RHS = S.ImpCastExprToType(RHS.get(), Type, CK_BitCast);
+ } else {
+// C++2a [expr.spaceship]p4
rsmith wrote:
> We still need to apply the usua
HsiangKai updated this revision to Diff 142533.
HsiangKai added a comment.
Update test cases.
Repository:
rC Clang
https://reviews.llvm.org/D45045
Files:
lib/CodeGen/CGDebugInfo.cpp
lib/CodeGen/CGDebugInfo.h
lib/CodeGen/CGStmt.cpp
test/CodeGen/debug-label-inline.c
test/CodeGen/debu
Also, we only use auto if the type of the variable is clear. Changes like
- for (ModuleFile &I : llvm::reverse(ModuleMgr)) {
+ for (auto &I : llvm::reverse(ModuleMgr)) {
are not desired.
On Sat, Apr 14, 2018, 11:09 AM Malcolm Parsons via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On S
mzolotukhin added a comment.
Hi,
I've been monitoring compile-time for quite a while, so let my put my 2 cents
here too.
> Who is the audience for this information?
> What information do they want from a time report?
> How do we present that information in a way that's not misleading (given
devnexen created this revision.
devnexen added reviewers: dberris, alexfh, alekseyshl.
Herald added a reviewer: EricWF.
Herald added a subscriber: cfe-commits.
- On platform supported by clang, libcxx is too.
- Adding explicitly to avoid to have to add manually.
Repository:
rC Clang
https://r
36 matches
Mail list logo
