https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/122873
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> Thanks @chandlerc this is great! I think I'd seen multiple reviews where
> someone saw the preprocessor tricks and suggested it was more suitable for
> tablegen. Too bad we hadn't done it before now, but many thanks to you for
> doing it.
>
> I was able to do some fairly mi
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/123460
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/123302
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Ping
https://github.com/llvm/llvm-project/pull/123308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -51,28 +57,71 @@ class StringToOffsetTable {
return II->second;
}
- // Emit the string using string literal concatenation, for better readability
- // and searchability.
- void EmitStringLiteralDef(raw_ostream &OS, const Twine &Decl,
-co
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/120861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
Note that the PR doesn't actually change the lines that `clang-format` changes
here, and the `clang-format` change makes these lines inconsistent with the
rest of the file, so I intentionally did not apply t
chandlerc wrote:
> > ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
>
> Note that the PR doesn't actually change the lines that `clang-format`
> changes here, and the `clang-format` change makes these lines inconsistent
> with the rest of the file, so I intentionally did n
chandlerc wrote:
For many of the comments -- this, like the previous PR, is script generated
based on the physical grouping of the current `.def` file. My preference would
be to land it without trying to massage to better utilize the TableGen
features, as I'd really like to get the first cut i
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/121043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/121043
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
This does maybe point at something that doesn't add much complexity -- I
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/120831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Thanks, merging! I've put the script here for posterity:
https://gist.github.com/chandlerc/de807ea073beac351f87c660e1d4b7a0
https://github.com/llvm/llvm-project/pull/120831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/120831
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/121043
>From 3314a7d9b2ab582769ce4b4438d24d31c280d9f8 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Tue, 24 Dec 2024 08:41:49 +
Subject: [PATCH] Bulk port 64-bit x86 builtins to TableGen
This PR foll
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
Sure, I use the Fish shell and have a bunch of command line tools that he
chandlerc wrote:
Updated to rebase on top-of-tree with #120831 merged. Re-ran all the scripts to
verify things.
Using a variation on the command from my
[comment](https://github.com/llvm/llvm-project/pull/120831#discussion_r1903059479)
on the other PR:
```fish
diff -u (rg '^TARGET' BuiltinsX
chandlerc wrote:
So looking through this, again, these are all done initially by automation. And
the simple current form of that automation preserves the order of builtins in
the `.def` file, and so can only merge groups when they are precisely adjacent.
FWIW, I can add logic to my script to i
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
Ok, PR updated with an explicit opt-in for OpenCL `long` type support.
S
chandlerc wrote:
Ping, rebased to top-of-tree.
@phoebewang -- I think you're the most relevant reviewer here. If the `O` vs.
`LL` thing is really a blocker despite the added information, I'd like to know
so I can explore options to switch back. All of the ones I've come up with add
complexity
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/120861
>From e50a1dc121c00be4451d70b9bcdd1f3b6dbc98da Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Sat, 21 Dec 2024 23:42:57 +
Subject: [PATCH] Remove the `CustomEntry` escape hatch from buil
chandlerc wrote:
Rebased -- ping for a review in the new year maybe? I think this one is pretty
simple...
https://github.com/llvm/llvm-project/pull/120861
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/120835
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -108,9 +109,15 @@ class PrototypeParser {
} else if (T.consume_back("&")) {
ParseType(T);
Type += "&";
+} else if (T.consume_front("long long")) {
chandlerc wrote:
Not sure -- the vast majority of x86 builtins use `O` for this.
It's a n
chandlerc wrote:
> LLVM Buildbot has detected a new failure on builder `clang-debian-cpp20`
> running on `clang-debian-cpp20` while building `clang` at step 6
> "test-build-unified-tree-check-all".
>
> Full details are available at:
> https://lab.llvm.org/buildbot/#/builders/108/builds/7722
>
chandlerc wrote:
> > @dyung -- Ok, my latest attempt to work around these MSVC issues is now
> > pushed to this PR. It also contains a commit of specifically debugging
> > hacks to try and extract more information from any failure here. If you
> > could try doing another build with the latest
chandlerc wrote:
I've put the script in a gist here:
https://gist.github.com/chandlerc/de807ea073beac351f87c660e1d4b7a0
X-macros: the `BUILTIN(...)` macro invocations in an included file, where the
includer defines those macros to a specific pattern.
https://en.wikipedia.org/wiki/X_macro LLVM
chandlerc wrote:
@dyung -- Ok, my latest attempt to work around these MSVC issues is now pushed
to this PR. It also contains a commit of specifically debugging hacks to try
and extract more information from any failure here. If you could try doing
another build with the latest commit
([2ec750
@@ -68,23 +70,144 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
@@ -100,10 +244,17 @@ class Context {
/// Return the identifier name for the specified builtin,
/// e.g. "__builtin_abs".
- llvm::StringRef getName(unsigned ID) const { return getRecord(ID).Name; }
+ std::string getName(unsigned ID) const;
+
+ /// Return the identifier
@@ -100,10 +244,17 @@ class Context {
/// Return the identifier name for the specified builtin,
/// e.g. "__builtin_abs".
- llvm::StringRef getName(unsigned ID) const { return getRecord(ID).Name; }
+ std::string getName(unsigned ID) const;
chandlerc wrot
@@ -68,23 +70,144 @@ enum ID {
FirstTSBuiltin
};
+// The info used to represent each builtin.
struct Info {
- llvm::StringLiteral Name;
- const char *Type, *Attributes;
- const char *Features;
+ // Rather than store pointers to the string literals describing these four
https://github.com/chandlerc commented:
I think I've addressed most of the review comments here at this point.
But maybe most excitingly, I think the latest version may dodge the issues that
have cropped up with MSVC -- both LoongArch and X86 fixes have been
incorporated that hopefully help. @
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/120534
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -112,6 +112,16 @@ static constexpr std::array
MakeInfos(std::array Infos) {
return Infos;
}
+/// A shard of a target's builtins string table and info.
+///
+/// Target builtins are sharded across multiple tables due to different
+/// structures, origins, and also to impr
chandlerc wrote:
@dyung -- this PR is updated with new fixes. NVPTX hopefully works and neither
of my debugging checks fires. But there may still be some other failures I need
to chase down, let me know?
https://github.com/llvm/llvm-project/pull/120534
_
chandlerc wrote:
> @dyung -- this PR is updated with new fixes. NVPTX hopefully works and
> neither of my debugging checks fires. But there may still be some other
> failures I need to chase down, let me know?
Hmm, looks like there are likely to be ARM and Hexagon failures remaining at
least.
chandlerc wrote:
> > > @dyung -- this PR is updated with new fixes. NVPTX hopefully works and
> > > neither of my debugging checks fires. But there may still be some other
> > > failures I need to chase down, let me know?
> >
> >
> > Hmm, looks like there are likely to be ARM and Hexagon fail
chandlerc wrote:
> > Is there any hope of upgrading MSVC? I know you were looking at that, but
> > not sure what progress happened there.
>
> I didn't go through with it and was hoping you would be able to find a
> work-around. I'll start talking to people to try and do a stop-gap update to
>
t;for long strings.
>From da058f5c63bffa1459258092771874b7970da689 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Fri, 17 Jan 2025 08:31:45 +
Subject: [PATCH] Switch diagnostic group names to use `llvm::StringTable`
Previously, they used a hand-rolled Pascal-string encoding different
from all the othe
001
From: Chandler Carruth
Date: Fri, 17 Jan 2025 08:50:44 +
Subject: [PATCH] [StrTable] Switch the option parser to `llvm::StringTable`
Now that we have a dedicated abstraction for string tables, switch the
option parser library's string table over to it rather than using a raw
`const char*`
@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"],
"code-completion-with-fixits">,
def skip_function_bodies : Flag<["-"], "skip-function-bodies">,
HelpText<"Skip function bodies when possible">,
MarshallingInfoFlag>;
-def disable_free : Flag<["-"], "disab
https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/136213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"],
"code-completion-with-fixits">,
def skip_function_bodies : Flag<["-"], "skip-function-bodies">,
HelpText<"Skip function bodies when possible">,
MarshallingInfoFlag>;
-def disable_free : Flag<["-"], "disab
@@ -7889,9 +7889,13 @@ def code_completion_with_fixits : Flag<["-"],
"code-completion-with-fixits">,
def skip_function_bodies : Flag<["-"], "skip-function-bodies">,
HelpText<"Skip function bodies when possible">,
MarshallingInfoFlag>;
-def disable_free : Flag<["-"], "disab
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/136213
>From 6c53f36e9306d5abc50b9afcc1fe6a204d67c6e1 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Wed, 16 Apr 2025 22:57:18 +
Subject: [PATCH] Make the `-disable-free` flag more full featured
T
rom 541894c25062d69b66ac27632e4f90021956de38 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Fri, 18 Apr 2025 06:55:15 +
Subject: [PATCH] Remove no-op visibility markers
Richard Smith noticed that these are overridden by the surrounding
visibility `let` region. Remove them to avoid confusion.
T
chandlerc wrote:
Follow-up PR as requested: #136271
https://github.com/llvm/llvm-project/pull/136213
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rom 4e4ca5ab0f49252ea5a59c51fc1ddd0b43bcc5df Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Wed, 16 Apr 2025 22:57:18 +
Subject: [PATCH] Make the `-disable-free` flag more full featured
This lets us pass `-no-disable-free` to re-enable freeing memory for
example. This is especially helpful for library us
chandlerc wrote:
> You might want to change the `DisableFree` default for library uses so that
> users don't need to specify `-no-disable-free`.
>
> ```
> // Clang calls BuryPointer on the internal AST and CodeGen-related elements
> like TargetMachine.
> // This will cause memory leaks if
chandlerc added a comment.
This makes sense to me, but definitely wait for someone more familiar w/
Clang's IR gen to review...
https://reviews.llvm.org/D50678
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/ma
chandlerc added a comment.
In https://reviews.llvm.org/D47814#1206372, @krytarowski wrote:
> If there are no more comments, I will land this by the end of this week.
Just for the record, this is not OK and not how LLVM's code review works.
You can and must wait for review. I think Joerg alread
chandlerc added a comment.
(To be clear, this continues to not be related to this patch, but happy to
discuss...)
Comment at: include/stddef.h:55
// Re-use the compiler's max_align_t where possible.
#if !defined(__CLANG_MAX_ALIGN_T_DEFINED) && !defined(_GCC_MAX_ALIGN_T) &
chandlerc created this revision.
chandlerc added reviewers: echristo, rnk, craig.topper.
Herald added subscribers: hiraditya, mcrosier, sanjoy.
Herald added a reviewer: javed.absar.
This is in preparation for enabling *only* the call retpolines when
using speculative load hardening.
I've continue
chandlerc added a comment.
Thanks!
I'm going to go ahead and land this, but happy to iterate on anything if others
have comments.
Repository:
rL LLVM
https://reviews.llvm.org/D51150
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http:/
This revision was automatically updated to reflect the committed changes.
Closed by commit rC340515: [x86/retpoline] Split the LLVM concept of retpolines
into separate (authored by chandlerc, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D51150?vs=162130&id=162138#toc
Repos
chandlerc created this revision.
chandlerc added reviewers: rsmith, rnk, echristo, craig.topper, kristof.beyls.
Herald added subscribers: jfb, dexonsmith, steven_wu, hiraditya, eraman,
mcrosier, mehdi_amini, sanjoy.
Wires up the existing pass to work with a proper IR attribute rather
than just a
chandlerc added a comment.
Sorry folks, but you can't just take patches to libstdc++ and apply them to
libc++.
These libraries have different licenses, and so the author of the patch
(Jonathan Wakely in this case) need's to *explicitly* contribute that patch to
libc++ under libc++'s license. (
chandlerc added a comment.
In https://reviews.llvm.org/D46593#1093758, @jwakely wrote:
> @chandlerc thanks for catching this.
>
> As the original author I agree to contribute this patch to libc++ under the
> terms of the MIT and the University of Illinois licences, and under the terms
> of "Apa
chandlerc added inline comments.
Comment at: lib/Basic/Targets/X86.cpp:844-845
-// FIXME: Historically, we defined this legacy name, it would be nice to
-// remove it at some point. We've never exposed fine-grained names for
-// recent primary x86 CPUs, and we should
chandlerc added inline comments.
Comment at: lib/Basic/Targets/X86.cpp:844-845
-// FIXME: Historically, we defined this legacy name, it would be nice to
-// remove it at some point. We've never exposed fine-grained names for
-// recent primary x86 CPUs, and we should
chandlerc updated this revision to Diff 162319.
chandlerc marked 3 inline comments as done.
chandlerc added a comment.
Address review comments.
Repository:
rL LLVM
https://reviews.llvm.org/D51157
Files:
clang/include/clang/Driver/Options.td
clang/include/clang/Frontend/CodeGenOptions.def
chandlerc added a comment.
Thanks, should all be addressed now.
Comment at: clang/lib/Driver/ToolChains/Arch/X86.cpp:169-170
options::OPT_mno_retpoline_external_thunk, false)) {
// FIXME: Add a warning about failing to specify `-mretpoline` and
chandlerc updated this revision to Diff 162322.
chandlerc added a comment.
Add a test file that I somehow missed earlier (sorry about that).
Repository:
rL LLVM
https://reviews.llvm.org/D51157
Files:
clang/include/clang/Driver/Options.td
clang/include/clang/Frontend/CodeGenOptions.def
chandlerc updated this revision to Diff 162325.
chandlerc added a comment.
Move to a more conservative model suggested by Kristof.
Repository:
rL LLVM
https://reviews.llvm.org/D51157
Files:
clang/include/clang/Driver/Options.td
clang/include/clang/Frontend/CodeGenOptions.def
clang/lib/
chandlerc marked an inline comment as done.
chandlerc added inline comments.
Comment at: llvm/docs/LangRef.rst:1659-1661
+that hardening. It should also be possible to *not* harden a hot and/or
safe
+function and have code inlined there *not* be hardened (even if the gen
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
I mean, sure.
I really don't know that supporting this ever expanding diversity of build
strategies is worth its cost, but I don't see a specific reason to not take
this patch
Rep
chandlerc marked 5 inline comments as done.
chandlerc added a comment.
All outstanding comments addressed, and landing this. Thanks all for the
reviews and let me know if I missed anything.
Comment at: llvm/include/llvm/IR/Attributes.td:181-185
+/// Note that this uses the def
This revision was automatically updated to reflect the committed changes.
chandlerc marked an inline comment as done.
Closed by commit rL341363: [x86/SLH] Add a real Clang flag and LLVM IR
attribute for Speculative (authored by chandlerc, committed by ).
Changed prior to commit:
https://reviews
chandlerc added inline comments.
Comment at: docs/DeveloperPolicy.rst:395-408
+Commits with No Functional Change
+-
+
+It may be permissible to commit changes without prior review when the changes
+have no semantic impact on the code if the changes
chandlerc added inline comments.
Comment at: docs/DeveloperPolicy.rst:395-408
+Commits with No Functional Change
+-
+
+It may be permissible to commit changes without prior review when the changes
+have no semantic impact on the code if the changes
chandlerc accepted this revision.
chandlerc added a comment.
This looks really good to me and seems like a nice clarification of historical
practice. =D Thanks so much for driving an actual documentation update for
folks that simply would never know about these practices otherwise, I think it
w
chandlerc added inline comments.
Comment at: docs/CodingStandards.rst:514-516
+line of code. Some common editors will automatically remove trailing whitespace
+when saving a file which causes unrelated changes to appear in diffs and
+commits.
Meinersbur wrote:
>
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
Agreed.
Repository:
rC Clang
https://reviews.llvm.org/D43203
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.o
chandlerc added a comment.
(focusing on the LLVM side of this review for now)
Can you add an LLVM-based test? Can you add this to
`lib/Passes/PassRegistry.def`?
Comment at: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp:423
+
+class AARGetter {
+ FunctionAnalysisManager &A
chandlerc added a comment.
In https://reviews.llvm.org/D33525#766050, @timshen wrote:
> In https://reviews.llvm.org/D33525#764251, @chandlerc wrote:
>
> > (focusing on the LLVM side of this review for now)
> >
> > Can you add an LLVM-based test? Can you add this to
> > `lib/Passes/PassRegistry.d
chandlerc added inline comments.
Comment at: clang/lib/CodeGen/BackendUtil.cpp:913-914
+std::error_code EC;
+ThinLinkOS.emplace(CodeGenOpts.ThinLinkBitcodeFile, EC,
+ llvm::sys::fs::F_None);
+if (EC) {
The clang s
chandlerc added inline comments.
Comment at: llvm/test/Transforms/ThinLTOBitcodeWriter/new-pm.ll:1
+; RUN: opt -passes='lto' -debug-pass-manager -thinlto-bc
-thin-link-bitcode-file=%t2 -o %t %s 2>&1 | FileCheck %s --check-prefix=DEBUG_PM
+; RUN: llvm-bcanalyzer -dump %t2 | FileC
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
This patch LGTM whenever the underlying LLVM change lands, thanks
https://reviews.llvm.org/D33692
___
cfe-commits mailing list
cfe-comm
chandlerc created this revision.
Herald added subscribers: mcrosier, sanjoy, klimek.
This really is a collection of improvements to the rules for LLVM
include sorting:
- We have gmock headers now, so it adds support for those to one of the
categories.
- LLVM does use 'FooTest.cpp' files to test
chandlerc updated this revision to Diff 101544.
chandlerc added a comment.
Add test coverage for the case-insensitive category logic.
https://reviews.llvm.org/D33932
Files:
include/clang/Format/Format.h
lib/Format/Format.cpp
unittests/Format/SortIncludesTest.cpp
Index: unittests/Format/S
chandlerc marked an inline comment as done.
chandlerc added a comment.
Added more tests, PTAL?
https://reviews.llvm.org/D33932
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc updated this revision to Diff 103885.
chandlerc marked an inline comment as done.
chandlerc added a comment.
Update based on review comments.
https://reviews.llvm.org/D33932
Files:
include/clang/Format/Format.h
lib/Format/Format.cpp
unittests/Format/SortIncludesTest.cpp
Index:
chandlerc requested review of this revision.
chandlerc added a comment.
Tried to address the test comment -- let me know if something else was intended.
https://reviews.llvm.org/D33932
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://l
chandlerc added a comment.
In https://reviews.llvm.org/D36836#931995, @lebedev.ri wrote:
> - Rebased
> - As advised by @aaron.ballman, moved into it's own directory/module. Please
> review that, i'm not entirely sure i have done that fully correctly.
>
> @chandlerc Hi! @aaron.ballman has sugge
chandlerc edited reviewers, added: rnk, rsmith, rjmccall; removed: chandlerc.
chandlerc added a comment.
Adding more Clang CodeGen folks to this review rather than myself...
Repository:
rC Clang
https://reviews.llvm.org/D43995
___
cfe-commits mai
chandlerc added a comment.
In https://reviews.llvm.org/D42787#1000687, @krasimir wrote:
> We could adapt the single-argument version instead, turning:
>
> foo(bb +
> c);
>
>
> into:
>
> foo(bb +
> c);
>
I have a
chandlerc edited subscribers, added: brooksmoses, chandlerc; removed: rnk.
chandlerc edited reviewers, added: echristo, timshen, dlj; removed: kcc.
chandlerc added a comment.
Ok folks, I know this is a blast from the past, but can we actually review
this? I'm willing to commandeer it, rebase it,
chandlerc created this revision.
chandlerc added reviewers: craig.topper, rsmith.
Herald added subscribers: llvm-commits, atanasyan, kbarton, nemanjai, mcrosier,
sanjoy.
Herald added a reviewer: javed.absar.
This is important for C++ templates that essentially compute the valid
input in a way tha
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
LGTM, thanks!
https://reviews.llvm.org/D48462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman
This revision was automatically updated to reflect the committed changes.
Closed by commit rC335309: [x86] Teach the builtin argument range check to
allow invalid ranges in (authored by chandlerc, committed by ).
Changed prior to commit:
https://reviews.llvm.org/D48464?vs=152404&id=152411#toc
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
LGTM as a patch, but same as the other wait to land until the -dev thread
settles.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56690/new/
https://reviews.llvm.org/D56690
_
chandlerc added a subscriber: hans.
chandlerc added a comment.
Adding Hans so he can be aware of the progress.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56571/new/
https://reviews.llvm.org/D56571
___
cfe-commits mailing list
cfe-commits
chandlerc requested changes to this revision.
chandlerc added a comment.
This revision now requires changes to proceed.
Wow, thanks for the cleanups. This is much easier to read as a consequence. And
sorry it took a while to get you another round of review. Comments below.
Com
chandlerc added a comment.
There was a long discussion between two NetBSD maintainers about this (both
already in the reviewers list of this patch). I'm not sure if there is an
existing thread that would be better to follow up on as opposed to starting a
fresh thread.
I think the question was:
chandlerc added a comment.
Should likely add release notes about this.
Also might be worth sending a note to cfe-dev as a heads up and give folks some
time to say "wait wait".
Repository:
rC Clang
https://reviews.llvm.org/D54547
___
cfe-commits
chandlerc requested changes to this revision.
chandlerc added a comment.
This revision now requires changes to proceed.
I think this should be `internal-driver-option` and the text updated? I don't
think these are necessarily experimental, they're internals of the compiler
implementation, and no
chandlerc requested changes to this revision.
chandlerc added a comment.
This revision now requires changes to proceed.
Maybe update at least some of the tests using these targets to additionally run
with the new pass manager explicitly enabled via flag?
Comment at: clang/lib/
301 - 400 of 566 matches
Mail list logo
