https://github.com/chandlerc closed
https://github.com/llvm/llvm-project/pull/123548
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Sounds good, and thanks for all the reviews!
https://github.com/llvm/llvm-project/pull/123548
___
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/123460
___
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
@@ -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
@@ -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
chandlerc wrote:
Ping!
I've updated this to incorporate the changes in #123398 to the NVPTX.def file
this is replacing.
Adding the author & reviewers of that PR to this -- I'd really like to either
get this landed or figure out what other approach to use it avoid having to
continually update
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/123548
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Ping -- all the dependent changes have landed and this is ready to be reviewed
/ merged!
I've already had to update this as more string table using code landed, so I'd
like it to not wait too long...
https://github.com/llvm/llvm-project/pull/123548
___
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/123548
___
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/123548
>From ce7c655ceec7af22256967a9892ac00a9a2ae925 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Thu, 16 Jan 2025 21:29:40 +
Subject: [PATCH] [StrTable] Switch intrinsics to `StringTable` and work arou
chandlerc wrote:
> > I also so comments on the python script, but as I mentioned there, the
> > script is not code I'm suggesting to check in or maintain, merely
> > documenting for completeness. It was never written to be remotely readable
> > or clean, just to produce a verifiably equivalent
https://github.com/chandlerc closed
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
chandlerc wrote:
Ping -- a week now with no review.
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
@@ -117,13 +121,13 @@ class OptTable {
private:
// A unified string table for these options. Individual strings are stored as
// null terminated C-strings at offsets within this table.
- const char *StrTable;
+ const StringTable *StrTable;
chandlerc wrote
@@ -33,25 +33,26 @@ using namespace llvm::opt;
namespace {
struct OptNameLess {
- const char *StrTable;
- ArrayRef PrefixesTable;
+ const StringTable *StrTable;
chandlerc wrote:
(same as above)
https://github.com/llvm/llvm-project/pull/123308
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
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
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
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
chandlerc wrote:
> Some good news, everything seems to pass after your latest changes in this
> PR! I didn't believe it at first and did a clean rebuild and test to verify.
> In the end everything passed again.
>
> That being said, I am working on deploying an updated version of VS2019 to
> o
https://github.com/chandlerc created
https://github.com/llvm/llvm-project/pull/123548
**Note:** This PR depends on #123302 and #123308 -- only the last of the three
commits should be reviewed here.
---
Historically, the main example of *very* large string tables used the
`EmitCharArray` to wo
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:
@dyung - OK, I think the current just-pushed version of this PR is worth
another test.
I've taught the TableGen string table emission to go back to working around the
MSVC issues using a different table form that we used to use in LLVM when MSVC
had a reliable error on it. It
chandlerc wrote:
Pushed an update that rebases on main, and more notably use an improved script
that preserves the grouping of builtins and the comments describing them. I
noticed that there were interesting and important comments here, so I reworked
things so we don't lose any information.
h
chandlerc wrote:
> You mention the performance tradeoff of pascal strings v null terminated ones
> doesn't seem too important - I guess that's based on some judgement about
> where/how these are used/where the strlens end up happening that you've
> looked into? Could you summarize that in a bi
@@ -51,6 +53,14 @@ class StringTable {
constexpr Offset() = default;
constexpr Offset(unsigned Value) : Value(Value) {}
+constexpr bool operator==(const Offset &RHS) const {
chandlerc wrote:
Doh, done. Forgot to go back to this after the iterator
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/123302
>From c78d4a2fd8d04aa79bab0c65044781aa0b8ca004 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`
P
https://github.com/chandlerc created
https://github.com/llvm/llvm-project/pull/123308
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*`.
Also try to use the `StringTable::Offset` type rat
https://github.com/chandlerc created
https://github.com/llvm/llvm-project/pull/123302
Previously, they used a hand-rolled Pascal-string encoding different from all
the other string tables produced from TableGen. This moves them to use the
newly introduced runtime abstraction, and enhances that
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
>
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:
> @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?
https://github.com/llvm/llvm-project/pull/120534
_
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:
> ⚠️ 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
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:
> > @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:
@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
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
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
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
>
@@ -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
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 follows
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
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
@@ -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
@@ -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
@@ -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:
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
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
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 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 builtin TableGen
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
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
chandlerc wrote:
> > > Sure, I can test it. Just to confirm, what branch/commit should I be
> > > testing?
> >
> >
> > This PR has everything in it so you can just test it. There are 3 commits
> > on this branch that won't land here (they're under review in their own
> > PRs), but I've got t
chandlerc wrote:
> > 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. @dyung --
@@ -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
@@ -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
@@ -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. @
@@ -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
@@ -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
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
chandlerc wrote:
> When I was still involved in X86 my recollection was we primarily used LLi.
> It looks like there was a large replacement of LLi with Oi here
> fa8cd7691ac28d07f6a127ed26f0dbe49699bd59.
Yeah, this patch makes me think the change to `Oi` here is ultimately correct,
and focus
chandlerc wrote:
> > A long way from an expert on OpenCL, but it seems to not even have the
> > concept of `long long`, and `long` is defined as a 64-bit type (and just
> > optional for embedded stuff)?
> >
> > https://registry.khronos.org/OpenCL/sdk/3.0/docs/man/html/scalarDataTypes.html
>
>
chandlerc wrote:
A long way from an expert on OpenCL, but it seems to not even have the concept
of `long long`, and `long` is defined as a 64-bit type (and just optional for
embedded stuff)?
https://registry.khronos.org/OpenCL/sdk/3.0/docs/man/html/scalarDataTypes.html
https://github.com/llvm
https://github.com/chandlerc created
https://github.com/llvm/llvm-project/pull/120861
This was an especially challenging escape hatch because it directly forced the
use of a specific X-macro structure and prevented any other form of TableGen
emission.
The problematic feature that motivated th
chandlerc wrote:
> > * Systematically using `Oi` instead of `LLi` for the type `long long int`.
> > The `.def` file uses a mixture of `Oi` and `LLi`. I chose the shorter
> > encoding.
>
> The mixture use of `Oi` and `LLi` is a mess, but `Oi` has different meaning
> for OpenCL targets. I think
https://github.com/chandlerc created
https://github.com/llvm/llvm-project/pull/120835
This shows up in several places in order to match the quoting of other uses of
the same diagnostic. Handling it centrally simplifies the code and reduces
changes if the storage for builtin names changes.
Thi
chandlerc wrote:
No worries about delay, this gives me a credible target to resolve the rest of
the issues. I'll update this PR both to address review comments but also to try
and address the rest of the failures. Appreciate runs to validate these
updates. =]
https://github.com/llvm/llvm-proj
chandlerc wrote:
@dyung -- Could you try out
https://github.com/chandlerc/llvm-project/tree/shard-loongarch and see if that
works?
Notably, it includes one additional patch on top of this series:
https://github.com/chandlerc/llvm-project/commit/2d593288dc18c55307779ae82a18d024761356ad
This w
chandlerc wrote:
> > > Just to add some more details now that I've slept a bit...
> > > Previously there were errors in AArch64 and RISCV -- it'll be really
> > > useful to know if those are the only errors with this patch, are there
> > > new ones, and especially if the RISCV errors go away th
chandlerc wrote:
> > > > I'll try it and let you know. Give me about an hour or so.
> > >
> > >
> > > Awesome! But no huge rush, mostly just hoping this happens to dodge
> > > whatever has been tripping up things here.
> >
> >
> > Sorry for the delay, but the failures still seem to be presen
@@ -43,7 +43,8 @@ class LLVM_LIBRARY_VISIBILITY XCoreTargetInfo : public
TargetInfo {
void getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const override;
- ArrayRef getTargetBuiltins() const override;
+ std::pair>
chandlerc wrote:
> Overall, I'm positive on this, and think this is beneficial. If this is
> something we can get to settle (I recognize this is probably what you were
> talking about with the RFC to increase the 'required MSVC version'), I'm all
> for it.
Yeah, this was the motivation.
Th
chandlerc wrote:
> > > I'll try it and let you know. Give me about an hour or so.
> >
> > Awesome! But no huge rush, mostly just hoping this happens to dodge
> > whatever has been tripping up things here.
>
> Sorry for the delay, but the failures still seem to be present. :( (The tests
> are
chandlerc wrote:
> I'll try it and let you know. Give me about an hour or so.
Awesome! But no huge rush, mostly just hoping this happens to dodge whatever
has been tripping up things here.
https://github.com/llvm/llvm-project/pull/120534
___
cfe-comm
chandlerc wrote:
> > > @dyung - I believe this PR may be a credible path to address the issues
> > > hit with your MSVC builders, would appreciate any help testing it in
> > > advance if possible.
> >
> >
> > Sure, I'll give it a try
>
> You seem to still be working on it, can you tell me wh
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
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
chandlerc wrote:
@dyung - I believe this PR may be a credible path to address the issues hit
with your MSVC builders, would appreciate any help testing it in advance if
possible.
https://github.com/llvm/llvm-project/pull/120534
___
cfe-commits mailin
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/119638
___
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/119638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
Build bot with the issue is now online and failing as expected, merging this
revert to get in green (we hope).
https://github.com/llvm/llvm-project/pull/119638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
chandlerc wrote:
I see the build bot up and with the original failure, going to merge the revert
to hopefully make sure it goes green after that.
https://github.com/llvm/llvm-project/pull/118734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
chandlerc wrote:
> That was a mistake. I originally was going to update the build bot to a later
> version of Visual Studio as while it wouldn't match our internal
> configuration, it was still useful to have some Windows coverage of the
> components we build/test. I then changed my mind and w
chandlerc wrote:
So, the builder came back up, and is now passing without this landing...
Here is the first build after it came back up:
https://lab.llvm.org/buildbot/#/builders/46/builds/9173
And I went through the output and found a specific test that was failing, and
it seems to pass?
```
chandlerc wrote:
Sorry, let's keep discussion on the original PR -- I'll go post there.
https://github.com/llvm/llvm-project/pull/119638
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> I'm going to bring out Windows buildbot back online that was failing so that
> when you do submit the revert, the bot should go back to green. I am looking
> into this and will get back to you on the original bug when I find something.
So, the builder came back up, and is no
https://github.com/chandlerc updated
https://github.com/llvm/llvm-project/pull/119638
>From 333befd054fb5da81f1349c8eba7255aa4e3ec12 Mon Sep 17 00:00:00 2001
From: Chandler Carruth
Date: Wed, 11 Dec 2024 15:59:35 -0800
Subject: [PATCH 1/2] Revert "Switch builtin strings to use string tables
(#
https://github.com/chandlerc created
https://github.com/llvm/llvm-project/pull/119638
Reverts llvm/llvm-project#118734
There is currently a specific (unreleased?) version of MSVC and builder that
are crashing / failing on this code. We don't know why as all the other build
bots and at least s
chandlerc wrote:
Thanks for the careful review, merging! (And starting on the follow-ups!)
https://github.com/llvm/llvm-project/pull/119198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
https://github.com/chandlerc edited
https://github.com/llvm/llvm-project/pull/119198
___
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/119198
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
chandlerc wrote:
> No real updates here, but our internal builder did catch up to this commit
> and we are seeing the same (and a lot more) failures when this commit is
> merged into our downstream codebase. I was kind of hoping that it would pass
> so that it might indicate that the problem m
@@ -53,10 +53,8 @@ class OptTable {
public:
/// Entry for a single option instance in the option data table.
struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+
1 - 100 of 334 matches
Mail list logo
