rnk added a comment.
This just adds declarations. Are these functions provided by some Windows
runtime library? Don't you need to implement the intrinsics somewhere in order
for the apps that use them to run or link? Ideally, they should be implemented
as builtins.
https://reviews.llvm.org/D5
rnk added inline comments.
Comment at: lib/Tooling/InterpolatingCompilationDatabase.cpp:182-184
+ if (Arg->getOption().matches(driver::options::OPT_driver_mode)) {
+// Process --driver-mode.
+IsCLMode = std::strcmp(Arg->getValue(), "cl") == 0;
---
rnk added inline comments.
Comment at: lib/Tooling/InterpolatingCompilationDatabase.cpp:136
+ // Otherwise just check the clang file name.
+ return llvm::sys::path::stem(CmdLine.front()).endswith_lower("clang-cl");
+}
We support being called "CL.exe", but with
rnk added inline comments.
Comment at: lib/CodeGen/CodeGenModule.cpp:737
+// potentially could come from another DLL as DSO local.
+if (GV->hasExternalLinkage() && GV->isDeclaration() &&
+isa(GV) && !GV->isThreadLocal())
I think this linkage and d
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Comment at: test/CodeGen/dso-local-executable.c:14
+// MINGW-DAG: @bar = external global i32
+// MINGW-DAG: @weak_bar = extern_weak global i32
+// MINGW-DAG: declare dso_local
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
In https://reviews.llvm.org/D50564#1211477, @mstorsjo wrote:
> Not much more comments from me. The implementation seems reasonable, and
> works for one simple test I did (with an earlier revision of
rnk added inline comments.
Comment at: src/assembly.h:76-78
+ .section .drectve,"yn" SEPARATOR\
+ .ascii "-export:", #name, "\0" SEPARATOR\
+ .text
Maybe .pushsection / .popsection is better than assuming you were in .te
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rUNW libunwind
https://reviews.llvm.org/D51509
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bi
rnk added a comment.
Do we still need or want this? It doesn't look like it would hurt.
Repository:
rUNW libunwind
https://reviews.llvm.org/D50413
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listi
rnk added a comment.
So, basically, if we have no internal users for these typedefs, there's no
reason to clutter up headers that get installed into system header directories
everywhere with dead ifdefed out code. Sounds good to me, let's not do it.
Repository:
rUNW libunwind
https://review
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Comment at: src/assembly.h:76-78
+ .section .drectve,"yn" SEPARATOR\
+ .ascii "-export:", #name, "\0" SEPARATOR\
+ .text
---
rnk requested changes to this revision.
rnk added a comment.
This revision now requires changes to proceed.
Still needs a test.
https://reviews.llvm.org/D42370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mai
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm, thanks! I thought that was going to be more of a pain. :)
https://reviews.llvm.org/D51784
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rnk added inline comments.
Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5244
+ false))
+CmdArgs.push_back("-fvisibility-inlines-hidden");
+
takuto.ikuta wrote:
> hans wrote:
> > takuto.ikuta wrote:
> > > hans wrote:
> > > > Huh, does th
rnk added inline comments.
Comment at: CodeGen/CGDebugInfo.cpp:2842-2843
+
+// When emitting codeview, record if a C++ record is trivial type.
+if (CGM.getCodeGenOpts().EmitCodeView) {
+ if (CXXRD->isTrivial())
I think we might as well set it when em
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rCXXA libc++abi
https://reviews.llvm.org/D49638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-b
rnk added a comment.
Thanks!
In https://reviews.llvm.org/D49597#1171044, @thakis wrote:
> rnk, since zturner is out until Thu, can you take a look?
Yep.
Comment at: clang/lib/AST/MicrosoftMangle.cpp:1756
Quals = Quals.withoutObjCLifetime();
-if ((!IsPointer && Qu
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
I still think we probably want to flag individual constructors and destructors
as trivial, so we can decide whether to emit them or not in CodeViewDebug.cpp.
https://reviews.llvm.org/D45124
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
https://reviews.llvm.org/D49597
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk accepted this revision.
rnk added a comment.
Please avoid the extra enum case, and commit.
Comment at: include/clang/Basic/TargetInfo.h:1223
enum CallingConvKind {
CCK_Default,
This is poorly named. I'll try to send a patch to rename it after this l
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rC Clang
https://reviews.llvm.org/D49871
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rC Clang
https://reviews.llvm.org/D49466
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail
rnk added inline comments.
Comment at: test/CodeGen/exceptions-seh.c:10
+// RUN: %clang_cc1 %s -triple aarch64-windows -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s --check-prefix=X64-GNU
mgrang wrote:
> Is it OK to re-use the X64-GNU check
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
https://reviews.llvm.org/D50029
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk added subscribers: hans, thakis, samsonov, rnk.
rnk added a comment.
+@thakis @hans
I think this broke Chromium's distributed Mac ASan build.
I personally found the error message confusing for the reasons that @samsonov
mentioned back in 2015. It's not that ASan wasn't supported on the plat
rnk added a comment.
In https://reviews.llvm.org/D15225#1183132, @george.karpenkov wrote:
> @rnk could you clarify how did it break the distributed asanified build? If
> the slave compiler supports asan it should have this runtime, right?
Most open source distributed build systems wrap only co
rnk added a comment.
In https://reviews.llvm.org/D15225#1183318, @george.karpenkov wrote:
> @rnk changing subjects: will you be at the LLVM social on Thursday? Could we
> discuss it there?
Yes, we can and should, but I'd like update chromium's copy of clang before
then.
Repository:
rL LLV
rnk added a comment.
Does this do anything other than -DUNICODE? Maybe just translate it at the
driver level and skip the -cc1 flag?
Repository:
rC Clang
https://reviews.llvm.org/D50199
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rUNW libunwind
https://reviews.llvm.org/D50135
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bi
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm, ship it :)
Repository:
rC Clang
https://reviews.llvm.org/D42768
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
I'm guessing things were structured this way so that a function definition
could have its visibility set before giving it a body, i.e. it would look like
a declaration, but the visibility shou
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rC Clang
https://reviews.llvm.org/D43017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
These ABIInfo classes don't have any state, so just building one on the stack
as needed is the way to go. Thanks for the fix!
Repository:
rC Clang
https://reviews.llvm.org/D43016
__
rnk created this revision.
rnk added reviewers: smeenai, majnemer.
Herald added a subscriber: eraman.
Fixes PR36247, which is where WinEHPrepare replaces inline asm in
funclets with unreachable.
Make getBundlesForFunclet return by value to simplify some call sites.
https://reviews.llvm.org/D430
rnk accepted this revision.
rnk added a comment.
lgtm
This works even though we pass -Wa,-mbig-obj?
Repository:
rC Clang
https://reviews.llvm.org/D41597
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailma
This revision was automatically updated to reflect the committed changes.
Closed by commit rL324689: [WinEH] Put funclet bundles on inline asm calls
(authored by rnk, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D43033?vs=133263&id=1
rnk created this revision.
rnk added a reviewer: rsmith.
This fixes a flaw in our AST: PR27098
MSVC always gives plain enums the underlying type 'int'. Clang does this
as well, but we claim the enum is "fixed", as if the user actually wrote
': int'. It means we end up emitting spurious -Wsign-com
rnk updated this revision to Diff 133670.
rnk added a comment.
- Add test, update comments
https://reviews.llvm.org/D43110
Files:
clang/include/clang/AST/Decl.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/Type.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaTemplateInstantiateDec
rnk added a comment.
In https://reviews.llvm.org/D43110#1003171, @thakis wrote:
> Nice!
>
> Test?
Yeah, I forgot to get that in. From the test you can see that we have weirdly
different behavior in C and C++ mode. Do people care? This is pre-existing
behavior. My change makes the enum "unfixe
rnk added a comment.
In https://reviews.llvm.org/D43110#1004107, @rsmith wrote:
> Thanks! I'd noticed this weirdness but wasn't sure what we could do about it
> without breaking MS compat. I like this approach a lot.
Great, sorry for the delay.
> If we want to change the C behavior too, I thi
rnk added a comment.
In https://reviews.llvm.org/D43184#1005161, @majnemer wrote:
> Do I understand correctly that this workarounds a feature missing in lld?
> Does MinGW emit the same sorts of object files as clang in these scenarios?
You can see it that way, but having the linker synthesize
This revision was automatically updated to reflect the committed changes.
Closed by commit rL324913: [Sema] Don't mark plain MS enums as fixed
(authored by rnk, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D43110?vs=133670&id=133886#
This revision was automatically updated to reflect the committed changes.
Closed by commit rC324913: [Sema] Don't mark plain MS enums as fixed
(authored by rnk, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D43110?vs=133670&id=133887#toc
Repository:
rC Clang
https://revi
rnk added a comment.
In https://reviews.llvm.org/D43184#1005281, @smeenai wrote:
> FYI, binutils auto-import actually creates a fake IAT entry rather than using
> a dynamic initializer. I think it's actually a pretty cute trick.
> http://blog.omega-prime.co.uk/2011/07/04/everything-you-never-wa
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
It looks like we already generate llvm.assume() for these and that eventually
behaves the same as the unreachable instruction. Neat. :)
https://reviews.llvm.org/D43221
rnk accepted this revision.
rnk added subscribers: probinson, aprantl, dblaikie.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
---
Clang's builtin headers use `__attribute__((__nodebug__))` for this purpose. Do
you think we should follow this up by using artificial
rnk created this revision.
rnk added a reviewer: rsmith.
When the C++ committee changed the wording around non-type template
arguments, they naively thought that every global declarations address
would be a constant expression, but this is not the case. There is no
PE/COFF relocation that allows
rnk added inline comments.
Comment at: clang/lib/AST/ExprConstant.cpp:10166-10182
+EvalInfo Info(Ctx, Result, EvalInfo::EM_ConstantFold);
+Info.IsNonTypeTemplateArgument = true;
+LValue LV;
+if (!EvaluateLValue(this, LV, Info) || Result.HasSideEffects ||
+
rnk added a comment.
In https://reviews.llvm.org/D43184#1005534, @mstorsjo wrote:
> In https://reviews.llvm.org/D43184#1005281, @smeenai wrote:
>
> >
>
>
> A related observation on the topic of this: There's a subtle difference
> between what both GCC and MSVC does here, compared to clang. The c
rnk updated this revision to Diff 134510.
rnk added a comment.
- revise as discussed
https://reviews.llvm.org/D43320
Files:
clang/include/clang/AST/Expr.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/ExprConstant.cpp
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCXX/dllimport-conste
rnk added a comment.
Can you update the description to clarify that this is fixing a bug in the
indexing library? From the description it sounds like we have a serious bug in
FUNCDNAME codegen, which is not the case. CodeGen does the right thing. The
ASTContext API is just crappy, so the Index
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
Lgtm
We should go farther, IMO. `clang -g` should default to emitting codeview in an
MSVC environment.
https://reviews.llvm.org/D43700
___
cfe-commit
rnk added a comment.
Code looks good, but we should test it. Can you add a CodeGenCXX test that
shows the issue with FUNCDNAME? I see the issue with this program:
#include
int main() {
const char *s1 = ([]() { return __FUNCDNAME__; })();
const char *s2 = ([]() { return __FUNCDNAME__
rnk added a comment.
In https://reviews.llvm.org/D43621#1019724, @ruiu wrote:
> This change looks good to me, but I think we shouldn't check in an executable
> binary file. Can you create `ld.foo.exe` in the test? Since you don't
> actually run ld.foo.exe, creating that executable should be ver
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
https://reviews.llvm.org/D43621
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk accepted this revision.
rnk added a comment.
Thanks!
https://reviews.llvm.org/D43734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk created this revision.
These intrinsics are supposed to select to BT, BTS, etc instructions.
Those instructions actually perform a bitwise array indexing memory
operation that LLVM doesn't currently expose. This change implements
the shifting and array indexing in plain C.
Fixes PR33188
If
rnk added inline comments.
Comment at: lib/CodeGen/CGCleanup.cpp:458
InsertBefore = Invoke->getNormalDest()->getFirstInsertionPt();
+else if (isa(Inst))
+ InsertBefore = std::next(AllocaInsertPt->getIterator());
This doesn't seem right, `Inst` cou
rnk added inline comments.
Comment at: test/CodeGenCoroutines/coro-await-domination.cpp:33
+ int x = 42;
+ x = co_await A{};
+}
It looks like this is the expression in question. This expression should have
aggregate evaluation kind, not scalar. We don't need t
rnk added a comment.
This was filed as https://bugs.llvm.org/show_bug.cgi?id=33178
Isn't there a space in the mangling for vendor extensions? Can we use that here?
https://reviews.llvm.org/D33398
___
cfe-commits mailing list
cfe-commits@lists.llvm.
rnk accepted this revision.
rnk added inline comments.
This revision is now accepted and ready to land.
Comment at: test/CodeGenCoroutines/coro-await-domination.cpp:33
+ int x = 42;
+ x = co_await A{};
+}
rnk wrote:
> It looks like this is the expression in que
rnk added a comment.
Darn, I think Richard is right, the signed div/mod doesn't do the right thing
for negative values. Honestly I need to rig up a test case for this, and then
I'll come back to it.
What do you folks think is best:
- Add an LLVM intrinsic for this and use it
- Use inline assem
rnk added inline comments.
Comment at: include/clang/Basic/Attr.td:2421
-def SelectAny : InheritableAttr, TargetSpecificAttr {
+def SelectAny : InheritableAttr, TargetSpecificAttr {
let Spellings = [Declspec<"selectany">, GCC<"selectany">];
davide wrote:
> P
This revision was automatically updated to reflect the committed changes.
Closed by commit rL305224: Correct debug info bit offset calculation for
big-endian targets (authored by rnk).
Changed prior to commit:
https://reviews.llvm.org/D32745?vs=97773&id=102233#toc
Repository:
rL LLVM
https:
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
Looks good, and I did ask Richard about this in person before filing the bug
and he was in favor of it, so feel free to commit. If I'd known how easy it was
to implement and how few tests it would b
rnk added inline comments.
Comment at: test/SemaCXX/warn-throw-out-noexcept-func.cpp:1
+// RUN: %clang_cc1 %s -fdelayed-template-parsing -fcxx-exceptions
-fexceptions -fsyntax-only -Wexceptions -verify -std=c++11
+struct A {
aaron.ballman wrote:
> I believe you
rnk added inline comments.
Comment at: include/clang/Basic/Attr.td:2421
-def SelectAny : InheritableAttr, TargetSpecificAttr {
+def SelectAny : InheritableAttr, TargetSpecificAttr {
let Spellings = [Declspec<"selectany">, GCC<"selectany">];
Prazek wrote:
> r
rnk added inline comments.
Comment at: include/clang/Basic/Builtins.def:55
// W -> int64_t
+// l -> 'int' if builtin is a MS extensions and the target is Darwin/LP64.
+// Defaults to 'L' otherwise.
majnemer wrote:
> Why not just LP64? Seems arbitra
rnk added a comment.
If LSan is a runtime thing, why not use weak hooks or something to detect LSan
at runtime instead of using a macro?
https://reviews.llvm.org/D34210
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/c
rnk added inline comments.
Comment at: lib/AST/ASTContext.cpp:8551
+ break;
+}
case 'W':
majnemer wrote:
> bruno wrote:
> > bruno wrote:
> > > rnk wrote:
> > > > compnerd wrote:
> > > > > I agree with @majnemer. Why not base this on the Int64Type?
rnk added a comment.
Saleem, didn't something change here two months ago? Why do we want to bother
with all of this dllimport stuff in the frontend? It seems to break mingw and
add complexity for very little gain (avoiding linker provided thunks).
Repository:
rL LLVM
https://reviews.llvm.or
rnk added inline comments.
Comment at: include/clang/Basic/Builtins.def:55
// W -> int64_t
+// N -> 'L' if target is LP64, 'int' size otherwise.
// S -> signed
Fix the comment? "long" if target is LLP64, "int" otherwise?
Comment at:
rnk accepted this revision.
rnk added a comment.
lgtm, thanks for shuffling all the tests around!
https://reviews.llvm.org/D34377
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
Oh joy. :)
lgtm, thanks for debugging this. The difference makes sense after the fact when
you think about Win x64's approach to va_arg and /homeparams, and how that
isn't relevant for x86.
https
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Comment at: test/CodeGenObjCXX/arc-indirect.mm:19
+// CHECK-DARWIN: define internal void @"\01-[C object:struct:]"(<{ %0*, i8*,
i8*, %struct.S, [3 x i8] }>* inalloca)
+// CHE
rnk added inline comments.
Comment at: test/CodeGen/x86-ms-inline-asm-enum_feature.cpp:12
+ const int a = 0;
+ // CHECK-NOT: mov eax, [$$0]
+ __asm mov eax, [a]
rnk wrote:
> mharoush wrote:
> > rnk wrote:
> > > Use CHECK-LABEL, CHECK, and CHECK-SAME the way th
This revision was automatically updated to reflect the committed changes.
Closed by commit rC320730: [CodeGen][X86] Implement
_InterlockedCompareExchange128 intrinsic (authored by rnk, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D41032?vs=126641&id=126997#toc
Repository:
rnk added a comment.
This isn't sufficient, GlobalDCE will remove the internal constant. It's also
unlikely that the constant will survive `--gc-sections / -fdata-sections`. A
better solution would be to add a new attribute
(`__attribute__((nondiscardable))`? too close to `nodiscard`?) that add
rnk added a comment.
@compnerd's suggestion is still a decent one: https://reviews.llvm.org/D31372
Which, I think is just adding something wacky like `@swiftcc@__Swift@@` which
would demangle as `__Swift::swiftcc` if the demangler expected an NNS there. Of
course, it doesn't, so it won't demang
rnk added inline comments.
Comment at: lib/CodeGen/CodeGenModule.cpp:690-692
+ // Only handle ELF for now.
+ if (!CGM.getTriple().isOSBinFormatELF())
+return false;
Handling COFF here is probably trivial. Everything is dso_local unless it's
dllimport. Does
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
Looks good, sorry for the holiday delay.
https://reviews.llvm.org/D41318
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
We should also discuss LLD and PDBs here. That's made huge progress since 5.0.
Repository:
rC Clang
https://reviews.llvm.org/D41711
___
cfe-co
rnk added a comment.
In https://reviews.llvm.org/D41711#966983, @rnk wrote:
> We should also discuss LLD and PDBs here. That's made huge progress since 5.0.
Nevermind, we have LLD release notes for that.
Repository:
rC Clang
https://reviews.llvm.org/D41711
__
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
This means, link the CRT and other default libraries statically, but give me a
DLL, right? Just confirming.
Repository:
rC Clang
https://reviews.llvm.org/D43811
__
rnk added a comment.
In https://reviews.llvm.org/D43842#1022546, @rjmccall wrote:
> Okay. In that case, this seems correct, although it seems to me that perhaps
> `inalloca` is not actually orthogonal to anything else. In fact, it seems to
> me that maybe `inalloca` ought to just be a bit on
rnk created this revision.
rnk added a reviewer: rsmith.
This is PR36536.
There are a few ways to reach Sema::ActOnStartOfFunctionDef with a null
Decl. Currently, the parser continues on to attempt to parse the
statements in the function body without pushing a function scope or
declaration contex
rnk added a comment.
This looks right to me, but we should check with @hans since I think he touched
this code last.
Repository:
rC Clang
https://reviews.llvm.org/D43995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.o
rnk created this revision.
rnk added a reviewer: rsmith.
Before this patch, Sema pre-allocated a FunctionScopeInfo and kept it in
the first, always present element of the FunctionScopes stack. This
meant that Sema::getCurFunction would return a pointer to this
pre-allocated object when parsing cod
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rC Clang
https://reviews.llvm.org/D44087
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mail
This revision was automatically updated to reflect the committed changes.
Closed by commit rL326744: [msvc] Allow MSVC toolchain driver to find the
aarch64 / arm64 cross-compiler. (authored by rnk, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
Let's do this. I thought we'd already have a higher C++ standard version by
now, but apparently not.
https://reviews.llvm.org/D34365
___
cfe-commits m
rnk added a comment.
Yep, looks good. I'd leave renderscript alone. I think it's deprecated.
https://reviews.llvm.org/D34365
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk added a comment.
Thanks!
Comment at: clang/include/clang/Sema/Sema.h:1320
sema::FunctionScopeInfo *getCurFunction() const {
-return FunctionScopes.back();
+return FunctionScopes.empty() ? nullptr : FunctionScopes.back();
}
thakis wrote:
> The
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
I think Richard has been really busy preparing for some C++ committee function.
I think we should go forward with this.
https://reviews.llvm.org/D43990
__
This revision was automatically updated to reflect the committed changes.
Closed by commit rC326926: Push a function scope when parsing function bodies
without a declaration (authored by rnk, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D43980?vs=136635&id=137437#toc
Repos
This revision was automatically updated to reflect the committed changes.
Closed by commit rL326926: Push a function scope when parsing function bodies
without a declaration (authored by rnk, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.
rnk added a comment.
Thanks!
John touched this code last in https://reviews.llvm.org/rL112038 in 2010, so
maybe he has some thoughts on how to clean this and the follow-up. I think I'll
land this as is since it fixes the crash and we can discuss more improvements
in https://reviews.llvm.org/D4
rnk created this revision.
rnk added a reviewer: rjmccall.
This provides no measurable build speedup, but it reinstates an
optimization from r112038 that was lost in r179618. It requires moving
CapturedScopeInfo::Capture out to clang::sema, which might be too
general since we have plenty of other
rnk added a comment.
Thanks for investigating!
Comment at: lib/CodeGen/MicrosoftCXXABI.cpp:1206
+
+ for (const VBase &V : VBases) {
+if (!V.second.hasVtorDisp())
I think we can avoid the sort altogether if we iterate `RD->vbases()`, which
should already b
rnk updated this revision to Diff 137472.
rnk added a comment.
Bring back Sema::setFunctionHas* methods which internally do nothing when
called outside function scope. This appears to happen in practice when parsing
invalid code involving things like statement expressions, VLAs at global scope,
et
101 - 200 of 1990 matches
Mail list logo
