dwblaikie wrote:
> OK. I modified this PR in order to only make the changes that fix #73145 .
> Sorting will remain broken as it has been since 2021. I will provide another
> PR after this one gets merged.
Thanks, really appreciate your patience/understanding here - I know it's a bit
of a fus
dwblaikie wrote:
So what breakage is caused by the sorting failure? Can that behavior be tested
in some way to validate this change and ensure it doesn't regress in the future?
https://github.com/llvm/llvm-project/pull/73323
___
cfe-commits mailing li
dwblaikie wrote:
> I did have a related RFC, but the
> [proposal](https://discourse.llvm.org/t/rfc-improving-clangs-middle-and-back-end-diagnostics/69261/16?u=nickdesaulniers)
> from @rnk is a yak shave that I don't intend to pursue.
I'd push on that a bit more. As I mentioned on the phab revi
dwblaikie wrote:
> I.e., two `DIGlobalVariableExpression`s for the same `DIGlobalVariable`,
> which AFAICT would confuse `DwarfDebug` at the moment, which expects there to
> be a 1-to-1 mapping.
Would confuse `DwarfDebug` without your changes/this patch? Or only with this
patch?
(& hopefully
dwblaikie wrote:
> > So what breakage is caused by the sorting failure?
>
> @dwblaikie This is not causing a breakage. It is just not working as designed
> because the sort function has been comparing `""` against `""` since commit
> [e6830b6](https://github.com/llvm/llvm-project/commit/e6830b
dwblaikie wrote:
Should've mentioned this earlier, but we've been seeing crashes in lldb due to
this change (though possibly related to our use of GALA python/gdb interop
https://github.com/sivachandra/gala - we haven't isolated the failures from
that yet (though we've been using it for years,
dwblaikie wrote:
> > Should've mentioned this earlier, but we've been seeing crashes in lldb due
> > to this change (though possibly related to our use of GALA python/gdb
> > interop https://github.com/sivachandra/gala - we haven't isolated the
> > failures from that yet (though we've been usi
dwblaikie wrote:
Perhaps not surprisingly from the backtrace, the DIE that's tripping things up
is the DW_TAG_variable here:
```
0x3819: DW_TAG_class_type
DW_AT_name ("ScopedLockService")
DW_AT_declaration (true)
0x381b: DW_TAG_variable
dwblaikie wrote:
Yeah, that seems to do it:
```
struct t1 {
t1();
static int i;
};
int t1::i = 43;
int main() {
}
```
```
$ clang++-tot -gsplit-dwarf -g test.cpp
$ lldb ./a.out -o "b main" -o "run" -o "p t1::i" -batch
This is google-lldb.
Help: http://go/lldb. File a bug: http://go/lldb-bug.
dwblaikie wrote:
In our practical example this clearly reproduces in cases where the definition
is available in another .dwo within the same executable. So I'm guessing
something needs to go looking for a definition (& then if it can't find one,
fail gracefully) here. There's probably some abs
dwblaikie wrote:
Yes, in the totally reduced reproducer - another debugger might be able to do
this name lookup with only a declaration, but I understand that at least
Clang's AST expression evaluator wouldn't be able to handle this case. (though
perhaps the lldb-eval work will provide some op
@@ -0,0 +1,50 @@
+// REQUIRES: !system-windows
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/layer1.cppm -triple %itanium_abi_triple \
+// RUN: -emit-module-interface -o %t/foo-layer1.pcm
+// RUN: %clang_cc1 -std=c++20 %t/l
dwblaikie wrote:
Thanks!
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
(this sort of example reinforces my concerns expressed earlier that this kind
of silent change in behavior is problematic - moreso in the wild, rather than
in Google's fairly constrained environment (frequent updates, good test
coverage, and good bisection infrastructure, etc
https://github.com/dwblaikie approved this pull request.
Yeah, looks OK to me - sorry for the delay.
https://github.com/llvm/llvm-project/pull/75385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
dwblaikie wrote:
@ilya-biryukov any chance you/your folks could test this change for performance
implications in google? It's especially helpful to CERN, but the last iteration
of this direction had some regressions that stalled out progress on that
version a few years ago, so it'd be good to
dwblaikie wrote:
looking good from what I've tested - thanks again!
https://github.com/llvm/llvm-project/pull/72235
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie approved this pull request.
Looks OK but please skip the extra assert-only `CurrentKind` variable in favor
of testing the `CurrentDebugNames` value.
https://github.com/llvm/llvm-project/pull/77511
___
cfe-commits mailing l
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/77511
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -925,6 +926,7 @@ class DwarfDebug : public DebugHandlerBase {
/// Sets the current DWARF5AccelTable to use.
void setCurrentDWARF5AccelTable(const DWARF5AccelTableKind Kind) {
+CurrentKind = Kind;
dwblaikie wrote:
Could skip this variable and check
Author: David Blaikie
Date: 2022-03-24T18:53:14Z
New Revision: 7b498beef03ae07bb98796461a957af836074b92
URL:
https://github.com/llvm/llvm-project/commit/7b498beef03ae07bb98796461a957af836074b92
DIFF:
https://github.com/llvm/llvm-project/commit/7b498beef03ae07bb98796461a957af836074b92.diff
LOG:
Author: David Blaikie
Date: 2022-03-25T23:53:19Z
New Revision: 34b9b1ea4874b109b998d59a837f81f2f730001c
URL:
https://github.com/llvm/llvm-project/commit/34b9b1ea4874b109b998d59a837f81f2f730001c
DIFF:
https://github.com/llvm/llvm-project/commit/34b9b1ea4874b109b998d59a837f81f2f730001c.diff
LOG:
Neat!
On Tue, Mar 22, 2022 at 1:07 AM Petr Hosek via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Petr Hosek
> Date: 2022-03-22T01:06:30-07:00
> New Revision: abe997bb2dd61188784954ae866352740629985d
>
> URL:
> https://github.com/llvm/llvm-project/commit/abe997bb2dd61188784954ae86
Author: David Blaikie
Date: 2022-04-05T17:16:42Z
New Revision: bb3980ae9fa7e19540080285f2bf2d960ea802fc
URL:
https://github.com/llvm/llvm-project/commit/bb3980ae9fa7e19540080285f2bf2d960ea802fc
DIFF:
https://github.com/llvm/llvm-project/commit/bb3980ae9fa7e19540080285f2bf2d960ea802fc.diff
LOG:
Author: David Blaikie
Date: 2022-04-06T18:25:46Z
New Revision: 6b306233f78876a1d197ed6e1f05785505de7c63
URL:
https://github.com/llvm/llvm-project/commit/6b306233f78876a1d197ed6e1f05785505de7c63
DIFF:
https://github.com/llvm/llvm-project/commit/6b306233f78876a1d197ed6e1f05785505de7c63.diff
LOG:
Author: David Blaikie
Date: 2022-07-28T00:07:35Z
New Revision: 4e719e0f16933a8945a4e85db39fdad5afbede36
URL:
https://github.com/llvm/llvm-project/commit/4e719e0f16933a8945a4e85db39fdad5afbede36
DIFF:
https://github.com/llvm/llvm-project/commit/4e719e0f16933a8945a4e85db39fdad5afbede36.diff
LOG:
gt; From: cfe-commits On Behalf Of David
> > Blaikie via cfe-commits
> > Sent: Friday, June 24, 2022 1:08 PM
> > To: cfe-commits@lists.llvm.org
> > Subject: [clang] 4821508 - Revert "DebugInfo: Fully integrate ctor type
> > homing into 'limited&#
Author: David Blaikie
Date: 2022-07-28T00:45:00Z
New Revision: 4bb192b846854ab1dc49a2e4b2a2717a4e3a9b1e
URL:
https://github.com/llvm/llvm-project/commit/4bb192b846854ab1dc49a2e4b2a2717a4e3a9b1e
DIFF:
https://github.com/llvm/llvm-project/commit/4bb192b846854ab1dc49a2e4b2a2717a4e3a9b1e.diff
LOG:
Author: David Blaikie
Date: 2021-07-17T23:58:15-07:00
New Revision: dac582ad3a78b18bdd2e6615f1ec105ee05adfe1
URL:
https://github.com/llvm/llvm-project/commit/dac582ad3a78b18bdd2e6615f1ec105ee05adfe1
DIFF:
https://github.com/llvm/llvm-project/commit/dac582ad3a78b18bdd2e6615f1ec105ee05adfe1.diff
Any chance some of this series of patches could have test coverage
included? (like small clang test cases that exercise only a narrow part of
the codegen & works with force-opaque-pointers due to these changes?)
On Sat, Jul 17, 2021 at 9:48 AM Nikita Popov via cfe-commits <
cfe-commits@lists.llvm.
On Tue, Jul 20, 2021 at 11:52 AM Nikita Popov wrote:
> On Tue, Jul 20, 2021 at 8:27 PM David Blaikie wrote:
>
>> Any chance some of this series of patches could have test coverage
>> included? (like small clang test cases that exercise only a narrow part of
>> the codegen & works with force-opaq
Author: David Blaikie
Date: 2021-07-21T17:12:22-07:00
New Revision: a46c63c878a9e82ac2646926bb3d8237293ad15d
URL:
https://github.com/llvm/llvm-project/commit/a46c63c878a9e82ac2646926bb3d8237293ad15d
DIFF:
https://github.com/llvm/llvm-project/commit/a46c63c878a9e82ac2646926bb3d8237293ad15d.diff
Author: David Blaikie
Date: 2021-07-22T14:51:56-07:00
New Revision: 83225936af317e6bdd7103a8a039c51a29ce9f57
URL:
https://github.com/llvm/llvm-project/commit/83225936af317e6bdd7103a8a039c51a29ce9f57
DIFF:
https://github.com/llvm/llvm-project/commit/83225936af317e6bdd7103a8a039c51a29ce9f57.diff
Author: David Blaikie
Date: 2022-03-09T21:12:56Z
New Revision: 85ee1d3ca1d06b6bd3477515b8d0c72c8df7c069
URL:
https://github.com/llvm/llvm-project/commit/85ee1d3ca1d06b6bd3477515b8d0c72c8df7c069
DIFF:
https://github.com/llvm/llvm-project/commit/85ee1d3ca1d06b6bd3477515b8d0c72c8df7c069.diff
LOG:
Author: David Blaikie
Date: 2022-04-08T00:00:46Z
New Revision: 1cee3d9db77b2c62a03efe1cce45f627dcbe6457
URL:
https://github.com/llvm/llvm-project/commit/1cee3d9db77b2c62a03efe1cce45f627dcbe6457
DIFF:
https://github.com/llvm/llvm-project/commit/1cee3d9db77b2c62a03efe1cce45f627dcbe6457.diff
LOG:
Author: David Blaikie
Date: 2022-02-10T15:27:31-08:00
New Revision: 26c5cf8fa031f5143fd180fdc8d9dbc26a88e89e
URL:
https://github.com/llvm/llvm-project/commit/26c5cf8fa031f5143fd180fdc8d9dbc26a88e89e
DIFF:
https://github.com/llvm/llvm-project/commit/26c5cf8fa031f5143fd180fdc8d9dbc26a88e89e.diff
Author: David Blaikie
Date: 2022-02-15T11:58:40-08:00
New Revision: 1ea326634b582f5574e0b22b85e5b0c631b30dcf
URL:
https://github.com/llvm/llvm-project/commit/1ea326634b582f5574e0b22b85e5b0c631b30dcf
DIFF:
https://github.com/llvm/llvm-project/commit/1ea326634b582f5574e0b22b85e5b0c631b30dcf.diff
Author: David Blaikie
Date: 2022-05-22T01:15:34Z
New Revision: 0b903ef6aa0976a60d3f448837f3c43adaf09cc1
URL:
https://github.com/llvm/llvm-project/commit/0b903ef6aa0976a60d3f448837f3c43adaf09cc1
DIFF:
https://github.com/llvm/llvm-project/commit/0b903ef6aa0976a60d3f448837f3c43adaf09cc1.diff
LOG:
(when recommitting a patch it can be helpful to mention the revisions
of the previous commit/revert, the reason for the revert and what's
different in this version of the patch that addresses that issue (or
how was the issue otherwise addressed))
On Wed, May 18, 2022 at 1:59 PM Mitch Phillips via
Author: David Blaikie
Date: 2024-03-13T16:03:16Z
New Revision: f15a790fd383665ec4defa0711e975476fd8b18b
URL:
https://github.com/llvm/llvm-project/commit/f15a790fd383665ec4defa0711e975476fd8b18b
DIFF:
https://github.com/llvm/llvm-project/commit/f15a790fd383665ec4defa0711e975476fd8b18b.diff
LOG:
dwblaikie wrote:
FWIW, @jyknight's example fails to compile with GCC - succeeds with clang 18
release but assert-fails with clang 18 +Asserts build. (not sure about the
original/full internal reproduction - we have a way to run compile with
assertions enaled, but I'm not sure I'm holding it ri
dwblaikie wrote:
Reading LLVM IR lit CHECK lines from clang codegen is a bit difficult - could
you include some simple examples (perhaps from the new clang tests in this
patch) showing the DWARF output just as comments in this review for something
more easily glanceable?
As for flags - I assu
dwblaikie wrote:
+1 to @iains's comments about being careful about the introduction and naming
of driver flags & probably avoid it in this case, if possible, or try to make
it clearly experimental.
https://github.com/llvm/llvm-project/pull/85050
___
https://github.com/dwblaikie approved this pull request.
LGTM, seems consistent with the previous patch - thanks!
https://github.com/llvm/llvm-project/pull/86401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
dwblaikie wrote:
Hmm, actually - does this fix address /other/ ways a pack could appear, like
this? https://godbolt.org/z/oez8TbGqM
Presumably a pack could appear in a variety of expressions, not just wrapped in
parens - could be in a function call (as in the above example), or nested
arbitr
dwblaikie wrote:
> For those files in the repository that do need CRLF endings, I've adopted a
> policy of eol=crlf which means that git will store them in history with LF,
> but regardless of user config, they'll be checked out in tree with CRLF.
This ^ seems a bit problematic to me, though (
dwblaikie wrote:
> @dwblaikie Feel free to checkout this patch locally and see if it resolves
> the original issue - I won't merge it until you confirm it works or discover
> another issue that goes beyond the scope of this patch. (e.g. another
> aforementioned issue)
First glance it seems i
dwblaikie wrote:
Yep, the original code still crashes with this PR applied, and the reduced test
case comes down to something identical to the code shown in
https://github.com/llvm/llvm-project/pull/86401#issuecomment-2024151742 with a
stack trace that looks the same as the one caused by the t
dwblaikie wrote:
> > > > > @iains @dwblaikie Understood. And I thought the major problem is that
> > > > > there are a lot flags from clang modules. And it is indeed confusing.
> > > > > But given we have to introduce new flags in this case, probably we
> > > > > can only try to make it more c
@@ -1483,10 +1483,15 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl
*D) {
if (D->isThisDeclarationADefinition())
Record.AddCXXDefinitionData(D);
- // Store (what we currently believe to be) the key function to avoid
- // deserializing every method so we can c
@@ -41,9 +43,10 @@ Base::~Base() {}
// CHECK: @_ZTSW3Mod4Base = constant
// CHECK: @_ZTIW3Mod4Base = constant
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3M
@@ -60,11 +63,11 @@ int use() {
// CHECK-NOT: @_ZTSW3Mod4Base = constant
// CHECK-NOT: @_ZTIW3Mod4Base = constant
-// CHECK: @_ZTVW3Mod4Base = external unnamed_addr
+// CHECK: @_ZTVW3Mod4Base = external
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr cons
dwblaikie wrote:
> > Reading LLVM IR lit CHECK lines from clang codegen is a bit difficult -
> > could you include some simple examples (perhaps from the new clang tests in
> > this patch) showing the DWARF output just as comments in this review for
> > something more easily glanceable?
>
> A
https://github.com/dwblaikie created
https://github.com/llvm/llvm-project/pull/87018
Complete C++ type information can be quite expensive - and there's
limited value in representing every member function, even those that
can't be called (we don't do similarly for every non-member function
anyway
dwblaikie wrote:
Cleaning up some old branches - @pogo59 @rnk who commented on the original
https://reviews.llvm.org/D152017
I think the only outstanding thing was the flag name, I've renamed it from
`-gincomplete-types` to `-gomit-unreferenced-members` to try to address the
feedback. It's no
@@ -193,6 +193,20 @@ DwarfFissionKind getDebugFissionKind(const Driver &D,
const llvm::opt::ArgList &Args,
llvm::opt::Arg *&Arg);
+// Calculate the output path of the module file when compiling a module
@@ -3017,6 +3017,7 @@ defm prebuilt_implicit_modules :
BoolFOption<"prebuilt-implicit-modules",
def fmodule_output_EQ : Joined<["-"], "fmodule-output=">,
Flags<[NoXarchOption]>, Visibility<[ClangOption, CC1Option]>,
+ MarshallingInfoString>,
dwblaikie wrot
@@ -41,9 +43,10 @@ Base::~Base() {}
// CHECK: @_ZTSW3Mod4Base = constant
// CHECK: @_ZTIW3Mod4Base = constant
-// CHECK-INLINE: @_ZTVW3Mod4Base = linkonce_odr {{.*}}unnamed_addr constant
-// CHECK-INLINE: @_ZTSW3Mod4Base = linkonce_odr {{.*}}constant
-// CHECK-INLINE: @_ZTIW3M
@@ -1483,10 +1483,15 @@ void ASTDeclWriter::VisitCXXRecordDecl(CXXRecordDecl
*D) {
if (D->isThisDeclarationADefinition())
Record.AddCXXDefinitionData(D);
- // Store (what we currently believe to be) the key function to avoid
- // deserializing every method so we can c
dwblaikie wrote:
Thanks for continuing to look into this!
@cor3ntin - perhaps you've got some more thoughts on this too?
https://github.com/llvm/llvm-project/pull/86401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
dwblaikie wrote:
> As for impact, I believe @namhyung did some measurement for building the
> Linux kernel, and it does not have a significant impact.
That'd surprise me quite a bit - perhaps a self-host build of clang (ideally in
Google's build config, that being the one you and I care about
dwblaikie wrote:
Can't seem to load the image - and generally a copy/paste of the text is more
usable for everyone than a screenshot. If you could include the copy/pasted
text, that'd be handy, thanks!
https://github.com/llvm/llvm-project/pull/80814
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -5401,6 +5409,8 @@ std::string CGDebugInfo::GetName(const Decl *D, bool
Qualified) const {
// feasible some day.
return TA.getAsIntegral().getBitWidth() <= 64 &&
IsReconstitutableType(TA.getIntegralType());
+ case Template
dwblaikie wrote:
perhaps the llvm libSupport prats of this change should be unit tested in LLVM,
rather than only tested indirectly in clang?
https://github.com/llvm/llvm-project/pull/83989
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
dwblaikie wrote:
> I did the first part of the renaming @dwblaikie : looks good?
Hmm - this patch still seems to have both renamings in it, if I'm reading the
PR correctly? I take it from the subject that isn't the intent/the intent is
that his patch only does the ThreadPool->DefaultThreadPool
dwblaikie wrote:
Oh, maybe issues related to layered patches - this is intended to be submitted
after the introduction of the ThreadPoolInterface? But includes those changes
in this review at the moment (I still haven't figured out what we're doing for
dependent changes - and I thought the Th
https://github.com/dwblaikie approved this pull request.
Yeah, still not sure why something like `%clang -### -c -target x86_64 -g
-gsplit-dwarf %s` wouldn't change behavior on a darwin host and cause the check
for gnu-pubnames to fail there but if you say that works, guess that's OK &
if
https://github.com/dwblaikie approved this pull request.
Sounds OK to me.
(though several other instances of system_category are touched in this patch -
out of curiosity, how are those different from the one fixed case you called
out in JSONTransport.cpp? Are the other uses of system_category
dwblaikie wrote:
Cool cool - thanks for the extra context!
https://github.com/llvm/llvm-project/pull/84423
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
If you're debugging with lldb you should probably be using -glldb - if you're
doing that, certainly gnu-pubnames should not be enabled by default or
implicitly by gsplit-dwarf.
I'd say -gsplit-dwarf -glldb probably doesn't need any names/accelerator table
by default (any more
dwblaikie wrote:
The dev policy says "Avoid committing formatting- or whitespace-only changes
outside of code you plan to make subsequent changes to." - I think it's
reasonable to consider changing this, but probably under the "clang-format
everything" or a similar discussion (broad discussion
dwblaikie wrote:
Commit without precommit review is fine, especially from a code owner - if you
only wanted the PR for automated precommit checking, you can add the
`skip-precommit-approval` to indicate that the PR isn't intended for precommit
review. But, yeah, otherwise it's good that if som
dwblaikie wrote:
+1 to @pogo59's comment about pruning complete paths - I suspect they're in the
minority. Might be worth checking whether the `===` at the start and end is
markup for any particular thing (I /think/ the `-*- C++ -*-` is load bearing
for some editors to inform them this `.h` fi
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/82840
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Some test coverage would be good to help demonstrate the issue/fix
https://github.com/llvm/llvm-project/pull/83175
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -11,7 +11,6 @@
// NOINLINE-NOT: "-fsplit-dwarf-inlining"
// SPLIT-NOT: "-dumpdir"
// SPLIT: "-debug-info-kind=constructor"
-// SPLIT-SAME: "-ggnu-pubnames"
dwblaikie wrote:
has this lost coverage for non `-glldb` configurations?
(like would we still
dwblaikie wrote:
Presumably similar things might show up in macros? But can cross that bridge
when we come to it.
Perhaps we have some/could use some generic utility for this sort of contextual
warning "if these things are literally written next to each other, warn, but if
they came to be via
@@ -11,7 +11,6 @@
// NOINLINE-NOT: "-fsplit-dwarf-inlining"
// SPLIT-NOT: "-dumpdir"
// SPLIT: "-debug-info-kind=constructor"
-// SPLIT-SAME: "-ggnu-pubnames"
dwblaikie wrote:
> As discussed in original PR, #82840 , the idea is if -gsplit-dwarf with
> -
@@ -11,7 +11,6 @@
// NOINLINE-NOT: "-fsplit-dwarf-inlining"
// SPLIT-NOT: "-dumpdir"
// SPLIT: "-debug-info-kind=constructor"
-// SPLIT-SAME: "-ggnu-pubnames"
dwblaikie wrote:
Nah, I think that's probably fine without an explicit `-ggdb` test - though
w
dwblaikie wrote:
> level 20 is a sweet spot for both compression rate and compression time
I wonder how much this is overfitting for kernels of a particular size, though?
(is it making the window just large enough that there's some "memory" from one
kernel to the next - but a slightly larger k
@@ -1591,6 +1591,14 @@ static void checkConfigMacro(Preprocessor &PP, StringRef
ConfigMacro,
}
}
+static void checkConfigMacros(Preprocessor &PP, Module *M,
+ SourceLocation ImportLoc) {
+ clang::Module *TopModule = M->getTopLevelModule();
+ f
dwblaikie wrote:
> > Could you show the stack (omitting/annotating the repeated part) that leads
> > to failure? and/or the AST shape that leads to failure?
>
> See the test I added. All you need is ~10k overloads of a method in a class
> and a `using Base::func` in the derived class. The AST
dwblaikie wrote:
(Please don't send pull requests that aren't going to be reviewed - commit
directly instead. Otherwise it's unclear which pull requests are expecting
review (& should wait on it) and which pull requests don't need review.
Especially for new contributors, it'd be good to not gi
dwblaikie wrote:
I'd still idly vote against adding this flag/support - but if other modules
contributors feel it's the right thing to do, I won't stand in the way.
https://github.com/llvm/llvm-project/pull/79959
___
cfe-commits mailing list
cfe-commi
@@ -3424,6 +3445,26 @@ llvm::DIMacroFile
*CGDebugInfo::CreateTempMacroFile(llvm::DIMacroFile *Parent,
return DBuilder.createTempMacroFile(Parent, Line, FName);
}
+llvm::DILocation *CGDebugInfo::CreateTrapFailureMessageFor(
+llvm::DebugLoc TrapLocation, StringRef Prefix,
@@ -3424,6 +3445,26 @@ llvm::DIMacroFile
*CGDebugInfo::CreateTempMacroFile(llvm::DIMacroFile *Parent,
return DBuilder.createTempMacroFile(Parent, Line, FName);
}
+llvm::DILocation *CGDebugInfo::CreateTrapFailureMessageFor(
dwblaikie wrote:
There's currentl
@@ -346,6 +346,14 @@ class CGDebugInfo {
const FieldDecl *BitFieldDecl, const llvm::DIDerivedType *BitFieldDI,
llvm::ArrayRef PreviousFieldsDI, const RecordDecl *RD);
+ // A cache that maps artificial inlined function names used for
+ // __builtin_verbose_trap to
dwblaikie wrote:
Sure - wrote down my thoughts here:
https://discourse.llvm.org/t/prs-without-approvals-muddy-the-waters/76656 (my
understanding is that this (waiting for approval after sending out a review -
and that all PRs are reviews until we figure out a way to differentiate them)
is exi
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/80687
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie commented:
Generally seems like good stuff to write down - I'm not sure about the ABI
breaking version (that mostly seems like it would make more problems than
solutions).
Commented on some minor grammatical issues.
https://github.com/llvm/llvm-project/pull/80687
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
@@ -610,6 +610,345 @@ the following style significantly:
The key part of the tip is to reduce the duplications from the text includes.
+Ideas for converting to modules
+---
+
+For new libraries, we encourage them to use modules completely from day
301 - 400 of 1491 matches
Mail list logo
