dwblaikie wrote:
Yeah, I think given how wide the change is and the speculative nature of the
harm - probably best to abandon this for now. We can pick it up again if more
folks speak up/more evidence is presented that it's problematic.
https://github.com/llvm/llvm-project/pull/110692
@@ -211,6 +211,16 @@ New Compiler Flags
only for thread-local variables, and none (which corresponds to the
existing ``-fno-c++-static-destructors`` flag) skips all static
destructors registration.
+- The ``-fextend-lifetimes`` and ``-fextend-this-ptr`` flags have been ad
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 %s -emit-llvm -O2 -fextend-lifetimes -o - | FileCheck
--check-prefixes=CHECK-ALL,CHECK-O2 %s
+// RUN: %clang_cc1 %s -emit-llvm -O0 -fextend-lifetimes -o - | FileCheck
--check-prefixes=CHECK-ALL,CHECK-O0 %s
+
+// Checks that we emit the functi
@@ -2217,6 +2217,11 @@ bool CompilerInvocation::ParseCodeGenArgs(CodeGenOptions
&Opts, ArgList &Args,
Args.getAllArgValues(OPT_fsanitize_trap_EQ), Diags,
Opts.SanitizeTrap);
+ Opts.ExtendThisPtr =
+ Opts.OptimizationLevel > 0
dwblaikie wrote:
Thanks @jimingham - yeah, that makes sense. My original argument for being OK
with the de-canonicalization of typedefs was that they aren't load bearing
anyway. But if lldb puts load on them, that assumption doesn't hold.
Yeah, could check for angles or template parameter DIEs
dwblaikie wrote:
Not quite sure how we get to caching and template specializations and pretty
printers.
If we're still producing the typedef-style DWARF for these alias template
specializations - perhaps lldb could not cache pretty printers for typedefs? (I
guess the pretty printers shouldn't
https://github.com/dwblaikie approved this pull request.
Fair enough
https://github.com/llvm/llvm-project/pull/108300
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -gno-column-info
-triple=x86_64-pc-linux -emit-llvm %s -o - | FileCheck %s
+
+// The important thing is that the compare and the conditional branch have
+// locs with the same scope (the lexical block for the 'if'). B
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -gno-column-info
-triple=x86_64-pc-linux -emit-llvm %s -o - | FileCheck %s
+
+// The important thing is that the compare and the conditional branch have
+// locs with the same scope (the lexical block for the 'if'). B
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -gno-column-info
-triple=x86_64-pc-linux -emit-llvm %s -o - | FileCheck %s
+
+// The important thing is that the compare and the conditional branch have
+// locs with the same scope (the lexical block for the 'if'). B
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/106033
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
> This make sense to me, @dwblaikie wdyt?
Seems OK to me
https://github.com/llvm/llvm-project/pull/106033
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
What static analysis tool flagged this? Any idea why this particular null
dereference, when LLVM/Clang have loads of assumed-non-null pointers that are
dereferenced in a great many places?
https://github.com/llvm/llvm-project/pull/105556
___
dwblaikie wrote:
> Looking forward to trying this out!
>
> Should the new flag have some docs and maybe be mentioned in the release
> notes, or do we think it's not ready for prime time yet for some reason?
I'm /pretty/ neutral on that - it's got pretty clear behavior, etc (& in fact
some cla
dwblaikie wrote:
> > The motivation is as usual IWYU and similar refactoring - to reduce build
> > time and probablility of non-related source(s) recompile.
>
> I'm confused: as far as I know IWYU achieves the opposite of what you're
> describing actually: it adds more includes than strictly n
dwblaikie wrote:
Is there existing test coverage (like, if you add an assertion, instead of an
if/return - do any tests hit the assertion)? or could you add some?
https://github.com/llvm/llvm-project/pull/97933
___
cfe-commits mailing list
cfe-commits
https://github.com/dwblaikie approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/100767
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: David Blaikie
Date: 2024-07-25T21:52:14Z
New Revision: 8dd574236ccaa0a183278396cfec3068b832651a
URL:
https://github.com/llvm/llvm-project/commit/8dd574236ccaa0a183278396cfec3068b832651a
DIFF:
https://github.com/llvm/llvm-project/commit/8dd574236ccaa0a183278396cfec3068b832651a.diff
LOG:
@@ -98,3 +98,6 @@ enum E8 { A8 = -128, B8 = 127 } x8;
// CHECK-NOT: DIFlagEnumClass
// CHECK: !DIEnumerator(name: "A8", value: -128)
+// Forward declaration of an enum class.
+enum class Color : int;
+// CHECK-NOT: !DICompositeType(tag: DW_TAG_enumeration_type, name: "Color"
-
dwblaikie wrote:
also, if you're sending a pull request just because it's convenient (via the
web UI "revert" button) or to run presubmits but not for review, please include
the skip-presubmit-approval label so it's clear something isn't getting
committed without needed review
https://github.
dwblaikie wrote:
(if you don't need a code review for a change, you can commit it directly
without a pull request - if you're making a PR not for code review but for
presubmit checks, please label to `skip-precommit-approval` to clarify that you
aren't waiting for approval (and that the change
dwblaikie wrote:
> > That's a pretty substantial policy change to propose, and this probably
> > isn't the place to propose/discuss it. If that's your intent, probably best
> > to take that up on discord.
>
> I am not proposing a policy change. I believe the current policy is aimed at
> givin
dwblaikie wrote:
> Thanks @smanna12. I think this looks ok; returning null here does appear to
> be consistent with other overloads of `CreateTypeDefinition` for `RecordType`
> and `ObjCInterfaceType`. I agree with @Michael137 that it would be nice to
> have an example that fails the added con
dwblaikie wrote:
> Also, I think we presently have sufficient review bandwidth in clang proper,
> even including the area of modules, so that any non-trivial change can be
> reviewed, and I also propose that we abstain from trying to directly commit
> those.
That's a pretty substantial policy
dwblaikie wrote:
> I think the appropriate tag for such commits would be NFCI, and should still
> require PR and review.
Clarifying a couple of things here
1) I tend to agree the patch might've been a bit subtle and maybe split up into
smaller, independent parts (usual rules: [be an isolated c
@@ -185,6 +203,18 @@ CALL_AO(PackedMembers)
// CHECK: call void @llvm.memcpy.p0.p0.i64({{.*}} align 1 {{.*}} align 1
{{.*}}i64 16, i1 {{.*}})
// CHECK: ret ptr
+// WithEmptyField copy-assignment:
+// CHECK-LABEL: define linkonce_odr nonnull align {{[0-9]+}}
dereferenceable({
dwblaikie wrote:
> It looks like the presence of `static` on template variable specializations
> makes difference in the namespace context: https://gcc.godbolt.org/z/WGsreqbz8
>
> Specifically, the specializations not marked `static` result in an exported
> variable. Thus, we have seemingly va
@@ -0,0 +1,25 @@
+// RUN: not %clang -### -c --target=x86_64 -Wa,--crel %s 2>&1 | FileCheck %s
--check-prefix=NOEXP
+
+// NOEXP: error: -Wa,--allow-experimental-crel must be specified to use
-Wa,--crel. CREL is experimental and takes a non-standard section type code
+
+// RUN: %
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/97176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/97176
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/96699
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
> Minor nit: Probably don't need to explicitly define a diagnostic group, since
> it's only ever used for this diagnostic.
Not sure what the conventions are - but I rather like the normalization of
having the explicit group, better chance of finding the group/reusing it maybe?
dwblaikie wrote:
@cor3ntin ping on this?
https://github.com/llvm/llvm-project/pull/93430
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Oh, this code was touched really recently in
66df6141659375e738d9b9b74bf79b2317576042 (@augusto2112 ) (see notes in previous
comments about how this code should be generalized)
https://github.com/llvm/llvm-project/pull/93809
___
cfe-
dwblaikie wrote:
Here's the smallest patch that would put explicit alignment on any packed
structure:
```
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp
b/clang/lib/CodeGen/CGDebugInfo.cpp
index a072475ba770..bbb13ddd593b 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CG
dwblaikie wrote:
The other effects of `packed` are encoded (the changes to the member offsets)
but that's not the only effect, and we shouldn't use that effect (which isn't
guaranteed to be observable - as in the case of "packed struct with a single
member/that just happens to not have padding
dwblaikie wrote:
oh, slight misquote above - `aligned(1)` is a no-op, as that attribute can't
reduce the alignment...
But I think my argument still stands, roughly as - if increases in alignment
are explicitly specified, decreases in alignment should be too.
https://github.com/llvm/llvm-proj
dwblaikie wrote:
Ah, I think this right solution to /this/ case is that the compiler should be
emitting the alignment for the structure?
Like there's no way for the debugger to know that this structure is
underaligned at the moment:
```
struct __attribute__((packed)) t1 {
int i;
};
```
Which
dwblaikie wrote:
> Should we add a test for this flag? Something around existing tests in
> clang/test/CXX/temp/temp.spec/temp.expl.spec/p2-20.cpp and
> clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p1.cpp.
Oh, right, I did have a new test I meant to add, but that's a better place for
it - so I've
https://github.com/dwblaikie updated
https://github.com/llvm/llvm-project/pull/96699
>From a539afc7b81502ffcab7028bfe8266b8e32951d9 Mon Sep 17 00:00:00 2001
From: David Blaikie
Date: Tue, 25 Jun 2024 21:02:50 +
Subject: [PATCH 1/2] Clang: Add warning flag for storage class specifiers on
ex
@@ -86,6 +86,8 @@ DYNAMIC_TAG(RELRSZ, 35) // Size of Relr relocation table.
DYNAMIC_TAG(RELR, 36)// Address of relocation table (Relr entries).
DYNAMIC_TAG(RELRENT, 37) // Size of a Relr relocation entry.
+DYNAMIC_TAG(CREL, 38) // CREL relocation table
+
--
dwblaikie wrote:
Sent a patch to add a warning flag for the warning this patch uses:
https://github.com/llvm/llvm-project/pull/96699
With that, we could disable the warning during the compiler migration,
decoupling compiler migration from code cleanup.
https://github.com/llvm/llvm-project/pul
https://github.com/dwblaikie created
https://github.com/llvm/llvm-project/pull/96699
With the recent fix for this situation in class members (#93873) (for
which the fixed code is invalid prior to this patch - making migrating
code difficult as it must be in lock-step with the compiler migration,
dwblaikie wrote:
Hit an msan use-of-uninitialized on an internal use case (a tool that uses
Clang via API).
the test was compiling this source code:
```
#include
namespace proto2 {
struct Message {};
} // namespace proto2
struct FakeProto : proto2::Message {
const std::string& getter() cons
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -28,7 +29,7 @@ namespace llvm {
}
// Prefix of the name of the artificial inline frame.
-#define CLANG_TRAP_PREFIX "__clang_trap_msg"
+inline constexpr llvm::StringRef CLANG_TRAP_PREFIX = "__clang_trap_msg";
dwblaikie wrote:
The name should be changed to u
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
> > I will say, `-fno-eliminate-unused-debug-types` is a really heavy hammer
> > that makes debug info much larger - and my understanding was that games
> > tended to have trouble with large debug builds, so I'd be surprised if this
> > was a great path forward.
>
> Absolutel
https://github.com/dwblaikie approved this pull request.
Looks OK - one minor nit, I'd probably avoid defining CLANG_TRAP_PREFIX as a
macro, but instead as an inline or some other form of constant
https://github.com/llvm/llvm-project/pull/79230
___
cf
@@ -27,6 +27,9 @@ namespace llvm {
}
}
+// Prefix of the name of the artificial inline frame.
+#define CLANG_TRAP_PREFIX "__clang_trap_msg"
dwblaikie wrote:
inline StringRef? usual reasons to avoid macros, etc
https://github.com/llvm/llvm-project/pull/7923
dwblaikie wrote:
I will say, `-fno-eliminate-unused-debug-types` is a really heavy hammer that
makes debug info much larger - and my understanding was that games tended to
have trouble with large debug builds, so I'd be surprised if this was a great
path forward.
Do you have a small example o
dwblaikie wrote:
Yes, the initializers do have to be lazyily evaluated to be a conforming C++
compiler.
eg: this code must compile without error so far as I understand:
```
template
struct t1 {
static constexpr int x = 3 / Value;
};
t1<0> v1;
```
Though it seems MSVC doesn't implement this co
dwblaikie wrote:
I think my last comment/question is still open? How/why did the symbol name end
up dropping any llvm/clang component to avoid collisions with other names?
https://github.com/llvm/llvm-project/pull/79230
___
cfe-commits mailing list
cf
dwblaikie wrote:
happy with the test coverage, but I'm probably not the right person to review
th ecode in more detail
https://github.com/llvm/llvm-project/pull/91310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
dwblaikie wrote:
> That would mean if someone wrote `struct Empty {}; struct Z { Empty a,b,c;
> }`, we'd lower it to `{ [3 x i8] }` instead of `{%Empty, %Empty, %Empty}`,
> which is a bit ugly. Other than that, sure, I guess we could do that.
Ah, fair enough. Glad to understand and I don't fee
dwblaikie wrote:
> Oh, in this particular case, the issue isn't the computed datasize, it's that
> FieldDecl::isZeroSize() returns the wrong result. If that's the case, maybe
> we can just change FieldDecl::isZeroSize() to say the field is zero size? So
> essentially, we pretend all empty fiel
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/95174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Congrats on the milestone! Glad to have more of us together on the same version
for all the positive feedback loops, etc :)
https://github.com/llvm/llvm-project/pull/95164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:
dwblaikie wrote:
> G'day -- we've got some tests for -O0 that, with this patch applied, generate
> different code with-and-without the `-g` flag, if
> `-fdebug-info-for-profiling` is enabled. Example godbolt:
> https://godbolt.org/z/qooo5Eah1 .
>
> It seems the intention of this patch is gene
@@ -1830,6 +1830,9 @@ void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables
&CGVT,
if (VTable->hasInitializer())
return;
+ if (RD->shouldEmitInExternalSource())
+return;
dwblaikie wrote:
But this logic (using available externally definitions) i
@@ -1830,6 +1830,9 @@ void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables
&CGVT,
if (VTable->hasInitializer())
return;
+ if (RD->shouldEmitInExternalSource())
+return;
dwblaikie wrote:
Yes, and we do emit them in normal builds above -O0 if th
@@ -3239,6 +3239,12 @@ bool ASTReader::isConsumerInterestedIn(Decl *D) {
if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never)
return true;
+ // The dynamic class defined in a named module is interesting.
+ // The code generator needs to emit its vtable
@@ -1185,6 +1190,21 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
TSK == TSK_ExplicitInstantiationDefinition)
return false;
+ // Itanium C++ ABI [5.2.3]:
+ // Virtual tables for dynamic classes are emitted as follows:
+ //
+ // - If the cla
dwblaikie wrote:
Per ( https://llvm.org/docs/GitHub.html#updating-pull-requests ) please don't
force push, makes it hard to follow the changes to the review as they progress.
https://github.com/llvm/llvm-project/pull/75912
___
cfe-commits mailing list
@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
TSK == TSK_ExplicitInstantiationDefinition)
return false;
+ // Itanium C++ ABI [5.2.3]:
+ // Virtual tables for dynamic classes are emitted as follows:
+ //
+ // - If the cla
https://github.com/dwblaikie approved this pull request.
Looks worth a shot. Please commit this at a time where you can respond to bot
fail-mail for a while after the commit.
And ensure the commit message has most/all of the details of the original
commit, plus the original commit and revert h
Author: David Blaikie
Date: 2024-05-30T20:36:47Z
New Revision: 6e975ecf5c93c40d2f088425548eb6476332629c
URL:
https://github.com/llvm/llvm-project/commit/6e975ecf5c93c40d2f088425548eb6476332629c
DIFF:
https://github.com/llvm/llvm-project/commit/6e975ecf5c93c40d2f088425548eb6476332629c.diff
LOG:
@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
TSK == TSK_ExplicitInstantiationDefinition)
return false;
+ // Itanium C++ ABI [5.2.3]:
+ // Virtual tables for dynamic classes are emitted as follows:
+ //
+ // - If the cla
@@ -1802,6 +1802,12 @@ void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables
&CGVT,
if (VTable->hasInitializer())
return;
+ // If the class is attached to a C++ named module other than the one
+ // we're currently compiling, the vtable should be defined there.
+ i
dwblaikie wrote:
Could probably adjust the assertions to be `assert (debug || whatever)` rather
than `if (!debug) assert(whatever)`.
My understanding/expectation was that these assertions would be removed
entirely - that whatever generated the AST should just be trusted, whether it's
the debu
dwblaikie wrote:
Thanks! Sorry I didn't get to it sooner
https://github.com/llvm/llvm-project/pull/93767
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
> There is a broken test in CI:
> https://lab.llvm.org/buildbot/#/builders/272/builds/17864
Fixed in ea1ecb50fa831583241fc531153bd2c072955d29
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@li
Author: David Blaikie
Date: 2024-05-29T23:36:43Z
New Revision: ea1ecb50fa831583241fc531153bd2c072955d29
URL:
https://github.com/llvm/llvm-project/commit/ea1ecb50fa831583241fc531153bd2c072955d29
DIFF:
https://github.com/llvm/llvm-project/commit/ea1ecb50fa831583241fc531153bd2c072955d29.diff
LOG:
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/87018
___
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.
Fair enough - let's give it a go.
https://github.com/llvm/llvm-project/pull/81545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
https://github.com/dwblaikie commented:
Is there some test coverage that shows that unreferenced variables/functions
aren't included in the output?
https://github.com/llvm/llvm-project/pull/91310
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/dwblaikie approved this pull request.
approving mostly on the basis of my own previous approval on phab
https://github.com/llvm/llvm-project/pull/91423
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
@@ -1802,6 +1802,12 @@ void ItaniumCXXABI::emitVTableDefinitions(CodeGenVTables
&CGVT,
if (VTable->hasInitializer())
return;
+ // If the class is attached to a C++ named module other than the one
+ // we're currently compiling, the vtable should be defined there.
+ i
@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
TSK == TSK_ExplicitInstantiationDefinition)
return false;
+ // Itanium C++ ABI [5.2.3]:
+ // Virtual tables for dynamic classes are emitted as follows:
+ //
+ // - If the cla
@@ -1180,6 +1185,21 @@ bool CodeGenVTables::isVTableExternal(const
CXXRecordDecl *RD) {
TSK == TSK_ExplicitInstantiationDefinition)
return false;
+ // Itanium C++ ABI [5.2.3]:
+ // Virtual tables for dynamic classes are emitted as follows:
+ //
+ // - If the cla
dwblaikie wrote:
(a bunch of compiler-rt tests also use ulimit, but doesn't look like any llvm
core tests do... )
https://github.com/llvm/llvm-project/pull/79875
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
dwblaikie wrote:
there's a couple of tests that use `ulimit`
(`clang/test/SemaCXX/PR51712-large-array-constexpr-check-oom.cpp` and
`clang/test/PCH/leakfiles.test`) - so that technique could be used to test this
in a way that's fast enough to check in?
https://github.com/llvm/llvm-project/pull
dwblaikie wrote:
Ah, OK - guess this might not be an ABI issue, then - carry on :) (I'll leave
it to other Clang-y folks to do the rest of the review, the ABI issues were my
only concern)
https://github.com/llvm/llvm-project/pull/92103
___
cfe-commit
dwblaikie wrote:
> @dwblaikie This patch will bring Clang in line with GCC and MSVC:
> https://godbolt.org/z/nj715zbsW
would the change be ABI incompatible with previous versions of clang? If so,
then it'll need to be versioned in Clang's ClangABI handling, so that platforms
(like Sony's Play
dwblaikie wrote:
@MaskRay seems like this target might be too niche to go into LLVM at this
time? is it worth considering some bar before accepting such a thing into LLVM,
rather than encouraging folks to maintain such a thing in a branch for now?
https://github.com/llvm/llvm-project/pull/8784
@@ -4260,6 +4260,13 @@ defm strict_dwarf : BoolOption<"g", "strict-dwarf",
"the specified version, avoiding features from later versions.">,
NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
Group;
+defm omit_unreferenced_members : BoolOption<"g", "omit
dwblaikie wrote:
> I think the comment about `s/members/methods/` is still outstanding - I agree
> that methods is more descriptive than members.
Yeah, seems I'm outvoted here. I'm a bit of a pedant for the C++ standard
language, which doesn't talk about "methods", only "member functions". But
@@ -4260,6 +4260,13 @@ defm strict_dwarf : BoolOption<"g", "strict-dwarf",
"the specified version, avoiding features from later versions.">,
NegFlag, BothFlags<[], [ClangOption, CLOption, DXCOption]>>,
Group;
+defm omit_unreferenced_members : BoolOption<"g", "omit
@@ -2755,7 +2755,7 @@ CGDebugInfo::CreateTypeDefinition(const RecordType *Ty) {
// Collect data fields (including static variables and any initializers).
CollectRecordFields(RD, DefUnit, EltTys, FwdDecl);
- if (CXXDecl)
+ if (CXXDecl && !CGM.getCodeGenOpts().DebugOmitUnr
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -debug-info-kind=limited -gomit-unreferenced-members %s
-emit-llvm -o - | FileCheck %s
dwblaikie wrote:
Done
https://github.com/llvm/llvm-project/pull/87018
___
cfe-commits mailing
https://github.com/dwblaikie updated
https://github.com/llvm/llvm-project/pull/87018
>From 6834c245205d1e38a615e97217dada3cd941ed03 Mon Sep 17 00:00:00 2001
From: David Blaikie
Date: Fri, 2 Jun 2023 15:04:14 +
Subject: [PATCH 1/3] [DebugInfo] Add flag to only emit referenced member
functio
dwblaikie wrote:
How's this compare with other implementations clang is trying to be compatible
with (gcc (in the normal clang driver mode) and msvc (in clang-cl mode))? Would
this be an ABI break against them, or is this intended as an ABI fix to align
better with them? Or some third option?
@@ -3424,6 +3445,26 @@ llvm::DIMacroFile
*CGDebugInfo::CreateTempMacroFile(llvm::DIMacroFile *Parent,
return DBuilder.createTempMacroFile(Parent, Line, FName);
}
+llvm::DILocation *CGDebugInfo::CreateTrapFailureMessageFor(
dwblaikie wrote:
Eh, I'm not too
dwblaikie wrote:
Hmm, do other builtins actually end up as symbol names? I think most of them
lower to an instruction or two - I guess this one doesn't lower to an actual
symbol, only a DWARF symbol - but maybe that's still different enough it should
use an llvm or clang in the name... (sorry,
dwblaikie wrote:
@pogo59 - you might find this interesting in terms of bitrotten tests, etc.
https://github.com/llvm/llvm-project/pull/91854
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-com
dwblaikie wrote:
> Switched to 0x4014 (generic range) to retain linker errors while making
> the experimental status stand out. Add a comment to make the intention
> clearer.
Seems a bit weird/problematic, using something in the reserved range/not in a
user extension space, but I guess so
dwblaikie wrote:
> This approahc parallels the strategy used for
> [-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang](https://reviews.llvm.org/D125142),
> albeit a nicer name.
Fair enough - yeah, if we're wordsmithing this. Maybe "allow" would be a good
word, rather th
dwblaikie wrote:
Oh, and I take it there's no /official/ extension space in the SHT_* space? The
intent is to standardize it where it lies? (like use 20 for the shipped
version? Or eventually get some lower designation?) I understand tnhe hesitance
to use "SHT_LLVM" or the like (though equally
dwblaikie wrote:
Presumably this'll be split out into separate reviews for the components here?
(I'd guess llvm-mc then clang integrated assembler, with readobj and yaml2obj
in any order/don't have dependencies, unless they're needed for testing, in
which case I guess they come first?)
I hesi
dwblaikie wrote:
> Though we detect when the types aren't identical and don't try to use them
> interchangeably. The change extends the existing behavior for structs/unions
> to enums.
OK, still a bit confused though - "like in C++", I assume in C++ we reject
mismatched types coming from dif
1 - 100 of 1126 matches
Mail list logo
