rnk accepted this revision.
rnk added a reviewer: rnk.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm, thanks!
Repository:
rL LLVM
https://reviews.llvm.org/D25273
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
rnk added inline comments.
> CodeGenFunction.h:2964
> +private:
> + enum class MSVCIntrin;
> +
Does this work on Linux? I thought you had to give it an explicit underlying
type (enum class MSVCIntrin : unsigned;) to make that work.
https://reviews.llvm.org/D25264
__
rnk added a comment.
You should use git-clang-format or some equivalent to format your change.
> TargetInfo.h:597
> + StringRef getNormalizedGCCRegisterName(StringRef Name,
> +bool ReturnCanonical = false) const;
>
format
> TargetInfo.h:600
> + virtual StringRef getConstraintRegister(
rnk added a comment.
Looks good functionally with some surface level nits
> X86ISelLowering.cpp:31979
>break;
> }
>}
Let's check size 2 after size 1, it seems more logical, and is 1 is probably
the common case.
> X86ISelLowering.cpp:32025
>case 'Y':
> +// Impliment Y
rnk added inline comments.
> avx512-mask-op-inline_asm_specific.c:1
> +// RUN: %clang_cc1 %s -target-cpu skylake-avx512 -O0 -S -o - -Wall -Werror
> | FileCheck %s
> +// This test checks validity of inline assembly for avx512 supported
> constraint k and Yk along with the required
Please chec
Can we figure out why having an incremental stage1 is problematic? I want
to keep it that way to speed up the bot.
It sounds like the problem is that we do not delete the stage1 install
directory before installing to it, or our install step uses a glob that may
include stale files from previous bu
On Tue, Oct 11, 2016 at 9:34 AM, Justin Lebar wrote:
> > Can we figure out why having an incremental stage1 is problematic? I
> want to keep it that way to speed up the bot.
>
> The problem is that the cmake install rule that we use does not remove
> extra files that happen to be present in the i
This breaks MSVC 2013 builds:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30238/steps/run%20tests/logs/stdio
FAILED:
tools/clang/lib/Frontend/CMakeFiles/clangFrontend.dir/CacheTokens.cpp.obj
...
C:\b\slave\sanitizer-windows\llvm\tools\clang\lib\Frontend\CacheTokens.cpp(63)
: error C
Author: rnk
Date: Tue Oct 11 12:24:09 2016
New Revision: 283906
URL: http://llvm.org/viewvc/llvm-project?rev=283906&view=rev
Log:
Fix the build with MSVC 2013 after r283856
Modified:
cfe/trunk/lib/Frontend/CacheTokens.cpp
Modified: cfe/trunk/lib/Frontend/CacheTokens.cpp
URL:
http://llvm.org
rnk added a comment.
We shouldn't thread this kind of boolean all the way through name lookup. This
is the kind of thing that callers should configure on the LookupResult object
that they pass in.
https://reviews.llvm.org/D25458
___
cfe-commits ma
rnk added a comment.
Can you provide a more complete motivating example where our diagnostics were
bad? I'm having a hard time figuring it out from the test
https://reviews.llvm.org/D25458
___
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
Comment at: test/Sema/builtins-x86_64.c:17
+ v8ll vec8longlongs;
+ (void)__builtin_ia32_readeflags_u64(); //
expected-error{{use of unknown buil
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Repository:
rL LLVM
https://reviews.llvm.org/D24958
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailm
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Comment at: clang/include/clang/Sema/Sema.h:9238
+///
+/// if (CUDADiagBuilder(...) << foo << bar)
+/// return ExprError();
jlebar wrote:
>
rnk added a comment.
Nice! Looks like this wasn't too bad.
Comment at: clang/lib/Sema/SemaCUDA.cpp:546
+ // Externally-visible and similar functions are always emitted.
+ if (S.getASTContext().GetGVALinkageForFunction(FD) > GVA_DiscardableODR)
+return true;
--
rnk added inline comments.
Comment at: lib/CodeGen/CGBuiltin.cpp:2730
+llvm::AtomicOrdering::SequentiallyConsistent);
+return Builder.CreateSub(RMWI, ConstantInt::get(IntTy, 1));
}
Can you make a helper similar to MakeBinaryAtomicValue for inc/dec
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
Comment at: clang/include/clang/Sema/Sema.h:9244
/// CUDAKnownEmittedFns.
- llvm::DenseMap> CUDACallGraph;
+ llvm::DenseMap>
CUDACallGraph;
I think yo
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
https://reviews.llvm.org/D25541
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk added inline comments.
Comment at: lib/CodeGen/CGBuiltin.cpp:2730
+llvm::AtomicOrdering::SequentiallyConsistent);
+return Builder.CreateSub(RMWI, ConstantInt::get(IntTy, 1));
}
agutowski wrote:
> rnk wrote:
> > Can you make a helper similar to
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
lgtm
https://reviews.llvm.org/D25576
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk created this revision.
rnk added a reviewer: rsmith.
rnk added a subscriber: cfe-commits.
GCC documents that the alignment parameter is in bits and it must be:
- an integer constant
- a power of two
- a multiple of CHAR_BITS
- below an unspecified limit
This lines up directly with the requir
These kinds of crashes typically happen when you have something like a
use-after-destroy of a temporary, like a misuse of Twine or
std::initializer_list.
On Thu, Oct 13, 2016 at 3:47 PM, Arnold Schwaighofer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: arnolds
> Date: Thu Oct 13
Author: rnk
Date: Mon Nov 27 15:42:20 2017
New Revision: 319116
URL: http://llvm.org/viewvc/llvm-project?rev=319116&view=rev
Log:
[clang-cl] Alias /Wall to -Weverything
cl interprets this option to mean enable every supported warning, which
is what Clang's -Weverything flag does.
Modified:
c
I see a bunch of link errors that suggest we're using the wrong EH
personality in MSVC mode now:
FAILED: win_clang_nacl_win64/swiftshader/libEGL.dll
win_clang_nacl_win64/swiftshader/libEGL.dll.lib
win_clang_nacl_win64/swiftshader/libEGL.dll.pdb
C:/b/depot_tools/win_tools-2_7_6_bin/python/bin/pytho
Author: rnk
Date: Wed Nov 29 10:45:03 2017
New Revision: 319336
URL: http://llvm.org/viewvc/llvm-project?rev=319336&view=rev
Log:
[clang-cl] Alias /wd4018 to -Wno-sign-compare
This warning is known to be noisy and projects frequently disable it. In
particular, this should make building isl as bun
Author: rnk
Date: Wed Nov 29 13:35:34 2017
New Revision: 319363
URL: http://llvm.org/viewvc/llvm-project?rev=319363&view=rev
Log:
[EH] Use __CxxFrameHandler3 for C++ EH in MS environments
Fixes regression introduced by r319297. MSVC environments still use SEH
unwind opcodes but they should use th
Author: rnk
Date: Wed Nov 29 13:36:00 2017
New Revision: 319364
URL: http://llvm.org/viewvc/llvm-project?rev=319364&view=rev
Log:
Reformat switch statement added in r319297, NFC
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:
http
On Wed, Nov 29, 2017 at 12:21 PM, Martin Storsjö wrote:
> On Wed, 29 Nov 2017, Martell Malone via cfe-commits wrote:
>
>> Thanks for letting me know Reid.
>> I’ll in work and won’t be able to access the repo until lunch time. (~3
>> hours)
>> Feel free to revert if it is not trivial.
>>
>> The ea
On Thu, Nov 30, 2017 at 10:21 AM, Dan Olson via Phabricator <
revi...@reviews.llvm.org> wrote:
> dolson added a comment.
>
> Hello,
>
> In the process of upgrading from clang 3.6.1 to a newer version, I ran
> into this new error and thus imported the new intrinsics from intrin.h for
> rep movsb an
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/71488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3507,6 +3507,9 @@ static llvm::StoreInst
*findDominatingStoreToReturnValue(CodeGenFunction &CGF) {
return nullptr;
// These aren't actually possible for non-coerced returns, and we
// only care about non-coerced returns on this code path.
+// All memory i
https://github.com/rnk commented:
Makes sense, small nit
https://github.com/llvm/llvm-project/pull/71488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/71488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
> I guess that's
> https://github.com/llvm/llvm-project/commit/b2615aa44d0cabd821b7afe5acdc847af9937c76...
> but I'm pretty sure we fixed -fdata-sections so the backend automatically
> generates comdats. So maybe we should just revert that.
That seems reasonable, however, there are
rnk wrote:
> In the testcase, the lambda is just at global scope. Not sure what you're
> expecting to happen here.
I think that's what I'm trying to get at, this strategy is incomplete and
didn't work.
I think a principled fix to the general problem would be to incorporate the
anonymous name
rnk wrote:
Do folks feel like the attribute name is sufficiently descriptive? i.e. should
it be `__attribute__((code_model("asdf")))`? Are we aiming for GCC compat here?
What guides the naming choice?
https://github.com/llvm/llvm-project/pull/72078
_
rnk wrote:
Here's a [GCC doc
link](https://gcc.gnu.org/onlinedocs/gcc/IA-64-Variable-Attributes.html). I
think matching GCC is sufficient motivation for me, I just didn't see it
mentioned.
https://github.com/llvm/llvm-project/pull/72078
___
cfe-comm
rnk wrote:
> @rnk -- what's the best way to check for compilation with microsoft's
> stardard C++ library?
If Clang is compiling with the MSVC STL headers, it should be defining
`_MSC_VER`, usually `-fms-compatibilty` has to be enabled to compile MSVC STL
headers. However, I searched, and it
https://github.com/rnk commented:
> I assume that /volatile:ms is a legacy behavior that non-Windows OSes likely
> don't want to adopt.
That is correct, it is legacy behavior. However, I think this flag has
potential porting applications, similar to `-fshort-wchar`. I also think
operating sys
rnk wrote:
@david-xl , Zequan posted an
[RFC](https://discourse.llvm.org/t/rfc-add-binary-profile-correlation-to-not-load-profile-metadata-sections-into-memory-at-runtime/74565/8)
for this. Is there a PGO tag, or something we can use to increase visibility
for PGO reviewers? I think most of th
https://github.com/rnk approved this pull request.
> And it's a pretty straightforward extension to support (it just slightly
> modifies IR generation), so I don't think there's much long-term support
> burden.
I find that compelling, but make sure others' concerns are addressed.
https://gith
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/71748
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
Do we really need to have all 4 variants of the 3 fortran runtime libraries?
That's a lot of complexity. Can we pare it down to just static/dynamic? It's
also sometimes possible to generate code that works in both the static and
dynamic context, depending on what is in those librari
rnk wrote:
> Do we really need to have all 4 variants of the 3 fortran runtime libraries?
> That's a lot of complexity. Can we pare it down to just static/dynamic? It's
> also sometimes possible to generate code that works in both the static and
> dynamic context, depending on what is in those
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/70833
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
> If we land this as-is, it'll tank build time on Windows.
While this is true, I don't think it's the right tradeoff for us to leave Intel
intrinsics inaccessible for users who don't want to enable new
microarchitectural features globally with command line flags. You may recall
the
rnk wrote:
> > What I'd like to see is a pull request sent to
> > https://github.com/microsoft/stl with some agreement about how to structure
> > the ifdefs so we can use intrin0.h when it is available.
>
> Sounds good I'll do that.
Thanks!
> I was thinking I could use `__has_include_next`.
rnk wrote:
> > I would like some measurements so we can compare build times on Windows.
>
> I took some benchmarks with `-ftime-trace` on the parse times with and
> without this change.
> ...
> clang-cl built with this PR frontend took ~1368ms to parse. `intrin.h` took
> ~969ms to parse. Most
Author: Reid Kleckner
Date: 2022-06-30T14:08:25-07:00
New Revision: 56dc4dbe45e2b1a3e33ab69323ae9d885ab34899
URL:
https://github.com/llvm/llvm-project/commit/56dc4dbe45e2b1a3e33ab69323ae9d885ab34899
DIFF:
https://github.com/llvm/llvm-project/commit/56dc4dbe45e2b1a3e33ab69323ae9d885ab34899.diff
Author: Reid Kleckner
Date: 2021-07-26T12:25:29-07:00
New Revision: 323049329939becf690adbeeff9f5f7e219075ec
URL:
https://github.com/llvm/llvm-project/commit/323049329939becf690adbeeff9f5f7e219075ec
DIFF:
https://github.com/llvm/llvm-project/commit/323049329939becf690adbeeff9f5f7e219075ec.diff
Author: Reid Kleckner
Date: 2021-07-26T15:48:32-07:00
New Revision: a9b114c5dd68685e0e68dd9144454b44509c2f5f
URL:
https://github.com/llvm/llvm-project/commit/a9b114c5dd68685e0e68dd9144454b44509c2f5f
DIFF:
https://github.com/llvm/llvm-project/commit/a9b114c5dd68685e0e68dd9144454b44509c2f5f.diff
Author: Reid Kleckner
Date: 2021-07-26T16:14:28-07:00
New Revision: f9f56488e02d1c09a9cd4acde61ce1c712e71405
URL:
https://github.com/llvm/llvm-project/commit/f9f56488e02d1c09a9cd4acde61ce1c712e71405
DIFF:
https://github.com/llvm/llvm-project/commit/f9f56488e02d1c09a9cd4acde61ce1c712e71405.diff
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/86039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
I think it makes sense to remove carriage returns on checkin, but I'm not sure
it makes sense to add them back on checkout on Windows. Historically, it's been
really easy to write LLVM tests that fail when the source is checked out with
CRLF. Many Windows developers have noted that
rnk wrote:
> As a data point, I've been setting core.autocrlf=true on Windows for years.
If that's the case, my information is stale, which I accept.
> To be clear, this may do nothing on checkout if a user has set a config
> option.
That addresses my concerns.
https://github.com/llvm/llv
rnk wrote:
That's interesting! I wonder how long the /F flags have accepted trailing
colons. That form seems a lot more readable.
I went looking for examples of how to do this with fewer aliases, but it looks
like this is what is done currently:
https://github.com/llvm/llvm-project/blob/main/c
https://github.com/rnk approved this pull request.
https://github.com/llvm/llvm-project/pull/87209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/87209
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rnk wrote:
To restate the finding, 29% of .debug_info is describing class methods, at
least in Clang.
I think this is a useful mode, and we should land it as is. There are many
users up against the scaling limits of debug info size, and it's helpful to
have this as an option for experimentati
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/80519
>From 6ab5ba3f970eaaea542fbed09cae17d3666df6b3 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Sat, 3 Feb 2024 00:18:42 +
Subject: [PATCH 1/4] wip
---
clang/lib/AST/Expr.cpp | 12
https://github.com/rnk commented:
What are the next steps to work to land this? We're interested to try this out
for Chrome!
https://github.com/llvm/llvm-project/pull/75425
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
https://github.com/rnk commented:
Thanks! I added notes.
https://github.com/llvm/llvm-project/pull/80519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/80519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk closed https://github.com/llvm/llvm-project/pull/80519
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk approved this pull request.
I think there are risks to shadowing `yvals_core.h`, but @CaseyCarter is at
least aware of it
[here](https://github.com/microsoft/STL/issues/3634#issuecomment-1904956652).
Once Clang ships its own intrin0.h header, the MSVC STL can adjust thei
rnk wrote:
I'm short on time, so I can't respond to all the discussion here, but at a high
level, I agree with this direction and it's something I discussed with
Microsoft folks working on ASan in the past, so I'm happy to see it come
together.
There is a great deal of build configuration com
https://github.com/rnk created https://github.com/llvm/llvm-project/pull/82815
This behavior is true for all attributes, but this behavior can be surprising
for attributes which have function-wide effects, such as `optnone` and
`target`. Most other function attributes affect the prototype or se
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk commented:
Is it feasible to create a migration path from the static runtime to the
dynamic runtime? As written, this requires users to update their ASan builds at
the same time that they take this update. Is it possible to leave the static
runtime behind, create a migra
@@ -0,0 +1,81 @@
+//===-- sanitizer_win_thunk_interception.h -
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apa
https://github.com/rnk edited https://github.com/llvm/llvm-project/pull/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/rnk created https://github.com/llvm/llvm-project/pull/80519
This code was correct as written prior to C++17, which allowed bases to appear
in the initializer list.
Clang currently requires compound literal initializers at file scope to be
constants, which is how I tested thi
@@ -108,3 +109,22 @@ int computed_with_lambda = [] {
return result;
}();
#endif
+
+#if __cplusplus >= 201703L
+namespace DynamicFileScopeLiteral {
+// This covers the case where we have a file-scope compound literal with a
+// non-constant initializer in C++. Previously, we h
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/80519
>From 6ab5ba3f970eaaea542fbed09cae17d3666df6b3 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Sat, 3 Feb 2024 00:18:42 +
Subject: [PATCH 1/2] wip
---
clang/lib/AST/Expr.cpp | 12
@@ -108,3 +109,22 @@ int computed_with_lambda = [] {
return result;
}();
#endif
+
+#if __cplusplus >= 201703L
+namespace DynamicFileScopeLiteral {
+// This covers the case where we have a file-scope compound literal with a
+// non-constant initializer in C++. Previously, we h
rnk wrote:
> Also in the issue: #80510 you pointed out a crash bug. We should have the bug
> covered in the test case as well.
I think that is covered by the existing test case, instead of crashing, we now
reject with an error. In the future if we want to align with GCC as you
suggest, we'll
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/80519
>From 6ab5ba3f970eaaea542fbed09cae17d3666df6b3 Mon Sep 17 00:00:00 2001
From: Reid Kleckner
Date: Sat, 3 Feb 2024 00:18:42 +
Subject: [PATCH 1/3] wip
---
clang/lib/AST/Expr.cpp | 12
https://github.com/rnk approved this pull request.
Yep, we are fairly liberal about adding new clang options to the clang-cl mode,
especially if they are in the feature `-f` flag namespace, which we believe
will not conflict with MSVC flags.
https://github.com/llvm/llvm-project/pull/68921
rnk wrote:
I still support disabling delayed template parsing by default in all
configurations. Ultimately, this feature is a source of bugs, and we should
start the clock on its deprecation and removal. This, of course, involves real
work, and I haven't allocated any time (mine or others') to
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -Wconversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -Wbitfield-conversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armebv7-unknown-linux -Wbitfield-conversion \
+// RUN: -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -Wconversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -Wbitfield-conversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armebv7-unknown-linux -Wbitfield-conversion \
+// RUN: -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple
rnk wrote:
> I think there should be a proper Clang flag to control this, instead of
> requiring users to pass internal `-mllvm` flags. (Also the flag should be
> well documented.)
I believe Zequan did that at one point, but he ran into the problem that Rust
and Clang need to agree on the cov
rnk wrote:
We can definitely disable delayed template parsing in C++20 mode, I wouldn't
argue against that. Whoever actually does the work should decide how much
effort they are willing to put in. I'm just saying there are benefits to
starting the deprecation clock sooner, since it will ultima
@@ -7,6 +7,8 @@
//===--===//
#include <__memory/aligned_alloc.h>
+#include <__overridable_function>
rnk wrote:
If this is only needed from files in src/, can the file be moved out of
libcxx
@@ -0,0 +1,38 @@
+// -*- C++ -*-
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-
@@ -0,0 +1,38 @@
+// -*- C++ -*-
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-
rnk wrote:
I think option 1 isn't really a permanent solution. We have lots of clang tools
that need to find the resource directory, and it should happen automatically.
For option 2, we'd have to reimplement that for every other clang tool that
needs to find resources, like LLD as well.
Shoul
rnk wrote:
I think option 1 isn't really a permanent solution. We have lots of clang tools
that need to find the resource directory, and it should happen automatically.
For option 2, we'd have to reimplement that for every other clang tool that
needs to find resources, like LLD as well.
Shoul
Author: rnk
Date: Tue Aug 20 16:32:51 2019
New Revision: 369474
URL: http://llvm.org/viewvc/llvm-project?rev=369474&view=rev
Log:
Add triple to new test to try to pacify bots
Modified:
cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
Modified: cfe/trunk/test/CodeGenCXX/debug-info-atexit-
Author: rnk
Date: Tue Aug 27 10:52:03 2019
New Revision: 370087
URL: http://llvm.org/viewvc/llvm-project?rev=370087&view=rev
Log:
Move EH spec mismatches under -fms-compatibility
-fms-extensions is intended to enable conforming language extensions and
-fms-compatibility is intended to language ru
Author: rnk
Date: Fri Sep 6 15:55:26 2019
New Revision: 371269
URL: http://llvm.org/viewvc/llvm-project?rev=371269&view=rev
Log:
Use musttail for variadic method thunks when possible
This avoids cloning variadic virtual methods when the target supports
musttail and the return type is not covaria
Author: rnk
Date: Fri Sep 6 17:41:08 2019
New Revision: 371277
URL: http://llvm.org/viewvc/llvm-project?rev=371277&view=rev
Log:
Fix thunks.cpp test, don't FileCheck for anon namespace id
The anon namespace id is a hash of the main input path to the compiler,
which varies in the test suite becau
Author: rnk
Date: Fri Aug 4 14:52:00 2017
New Revision: 310137
URL: http://llvm.org/viewvc/llvm-project?rev=310137&view=rev
Log:
[Support] Use FILE_SHARE_DELETE to fix RemoveFileOnSignal on Windows
Summary:
Tools like clang that use RemoveFileOnSignal on their output files
weren't actually able
Author: rnk
Date: Fri Aug 4 14:52:25 2017
New Revision: 310138
URL: http://llvm.org/viewvc/llvm-project?rev=310138&view=rev
Log:
[libclang] Determinize order of platform availability attrs
Previously this code was doing std::sort on IdentifierInfo pointers. Now
it sorts alphabetically by platfor
Author: rnk
Date: Fri Aug 4 15:38:06 2017
New Revision: 310145
URL: http://llvm.org/viewvc/llvm-project?rev=310145&view=rev
Log:
Clean up some lambda conversion operator code, NFC
We don't need special handling in CodeGenFunction::GenerateCode for
lambda block pointer conversion operators anymor
Author: rnk
Date: Mon Aug 7 18:33:53 2017
New Revision: 310331
URL: http://llvm.org/viewvc/llvm-project?rev=310331&view=rev
Log:
[codeview] Fix class name formatting
In particular, removes spaces between template arguments of class
templates to better match VS type visualizers.
Modified:
cf
Author: rnk
Date: Mon Aug 7 18:36:16 2017
New Revision: 310332
URL: http://llvm.org/viewvc/llvm-project?rev=310332&view=rev
Log:
Fix openmp-offload.c test on Windows
Modified:
cfe/trunk/test/Driver/openmp-offload.c
Modified: cfe/trunk/test/Driver/openmp-offload.c
URL:
http://llvm.org/viewv
Author: rnk
Date: Tue Aug 8 13:30:14 2017
New Revision: 310410
URL: http://llvm.org/viewvc/llvm-project?rev=310410&view=rev
Log:
[codeview] Emit nested enums and typedefs from classes
Previously we limited ourselves to only emitting nested classes, but we
need other kinds of types as well.
This
Author: rnk
Date: Thu Aug 10 14:21:15 2017
New Revision: 310661
URL: http://llvm.org/viewvc/llvm-project?rev=310661&view=rev
Log:
Revert "[clang-tidy] Refactor the code and add a close-on-exec check on
memfd_create() in Android module."
This reverts commit r310630.
The new code broke on Windows
301 - 400 of 1541 matches
Mail list logo
