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
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
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
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
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:
(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
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
@@ -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:
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
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:
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:
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:
> > 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:
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,
@@ -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
@@ -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
@@ -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
@@ -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
https://github.com/dwblaikie approved this pull request.
SGTM
https://github.com/llvm/llvm-project/pull/75142
___
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.
Sounds good to me, thanks!
https://github.com/llvm/llvm-project/pull/75022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Still seems like an unfortunate and subtle silent change in behavior to me. But
*shrug* if folks who own these features think it's fine, so be it.
https://github.com/llvm/llvm-project/pull/74809
___
cfe-commits mailing list
cfe-commit
dwblaikie wrote:
> > Probably would be good to introduce the `-v1` version and require it first,
> > then eventually change the default - so people don't get a silent behavior
> > change? Even the existing users only using `*` and `.` need to change their
> > syntax to migrate to v2, right? Th
dwblaikie wrote:
Probably would be good to introduce the `-v1` version and require it first,
then eventually change the default - so people don't get a silent behavior
change? Even the existing users only using `*` and `.` need to change their
syntax to migrate to v2, right? They'll need to ch
dwblaikie wrote:
> To support access to such constants from LLDB we'll most likely have to have
> to make LLDB find the constants by looking at the containing class first.
Tangentially related to:
https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/31?u
dwblaikie wrote:
I'd still like to know more about what other implementations do - see ongoing
discussion on the original issue.
https://github.com/llvm/llvm-project/pull/74419
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
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:
> 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:
> 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:
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:
> 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
https://github.com/dwblaikie approved this pull request.
Sounds reasonable to me, thanks!
https://github.com/llvm/llvm-project/pull/73146
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
dwblaikie wrote:
> Splitting it wouldn't help with bisect, as we would continue having a broken
> commit.
Not sure I understand - presumably this bug has existed for a while, separate
from the qsort issue? So fixing it separately seems good so that patches do one
thing clearly - makes it easy
Does this diagnostic have test coverage, could it be expanded to check the
spelling here? (mostly as a motivation to ensure this diagnostic is
actually tested... )
On Mon, Nov 20, 2023 at 3:04 AM via cfe-commits
wrote:
>
> Author: Utkarsh Saxena
> Date: 2023-11-20T12:04:32+01:00
> New Revision:
dwblaikie wrote:
> This commit also fixes commit
> https://github.com/llvm/llvm-project/commit/d3676d4b666ead794fc58bbc7e07aa406dcf487a
> that caused all headers to have NameAsWritten set to a 0-length string
> without adapting compareModuleHeaders() to the new field.
Sorry, I don't quite und
dwblaikie wrote:
(part of the point is so that patches can be reverted as needed without having
to revert/reapply huge patches when they aren't actually dependent)
https://github.com/llvm/llvm-project/pull/73000
___
cfe-commits mailing list
cfe-commit
dwblaikie wrote:
Generally when we split things up, they're separate reviews and separate
commits. fixups are for necessary changes that need to be applied atomically
(fixes to the base patch in a pull request, etc).
https://github.com/llvm/llvm-project/pull/73000
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/73000
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2402,7 +2402,7 @@ void tools::checkAMDGPUCodeObjectVersion(const Driver &D,
unsigned tools::getAMDGPUCodeObjectVersion(const Driver &D,
const llvm::opt::ArgList &Args) {
- unsigned CodeObjVer = 4; // default
+ unsigned CodeObjVe
@@ -4708,12 +4708,12 @@ defm amdgpu_ieee : BoolOption<"m", "amdgpu-ieee",
NegFlag>, Group;
def mcode_object_version_EQ : Joined<["-"], "mcode-object-version=">,
Group,
- HelpText<"Specify code object ABI version. Defaults to 4. (AMDGPU only)">,
+ HelpText<"Specify code ob
https://github.com/dwblaikie closed
https://github.com/llvm/llvm-project/pull/71564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
I'm still really hesitant about this direction.
One starting concern: what happens if someone adds an overload, or other
interesting name resolution to the module? The downstream caller hasn't
textually changed, but it should be rebuilt because it should be calling a
differen
dwblaikie wrote:
(patches like this should probably be broken up - test changes to the defaults
in lld and llvm for instance don't depend on the change to the clang driver
which is the only real semantic change in this patch, right? So probably only
change the semantics of clang, and the tests
dwblaikie wrote:
https://github.com/llvm/llvm-project/blob/abd85cd473afedf112bf00630a22382fee4a7853/llvm/lib/CodeGen/GlobalMerge.cpp#L531
- this is around where I think we'd get a global with a location and a
non-empty expression
https://github.com/llvm/llvm-project/pull/72730
dwblaikie wrote:
> My understanding was that the DIExpression parameter to
> DIGlobalVariableExpression was empty for global variables with locations. So
> the patch just encodes the constant into that expression if it's otherwise
> empty.
I think in theory it can be non-empty (see what happe
https://github.com/dwblaikie approved this pull request.
Looks plausible to me, thanks!
https://github.com/llvm/llvm-project/pull/71564
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
Hmm, I can't quite tell from the test case updates in the patch, at least at a
glance: How does this get encoded at the IR level? Do we end up with two
DIGlobalVariableExpressions? One with the constant value expresison, and one
that references the actual global variable? Or s
@@ -0,0 +1,48 @@
+// RUN: %clang_cl --target=x86_64-windows-msvc /c /Z7 -o %t.obj -- %s
dwblaikie wrote:
Generally clang tests don't test end-to-end. If the code change only affects
clang IR generation, the test should only test clang IR generation, not all the
@@ -0,0 +1,65 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: split-file %s %t
+
+// RUN: %clang_cc1 -std=c++20 -emit-obj -fmodules -fimplicit-module-maps
-fmodules-cache-path=%t %t/main.cpp -o %t/main.o
+
+//--- V.h
+#ifndef V_H
+#define V_H
+
+class A {
+public:
+ constexpr A
https://github.com/dwblaikie approved this pull request.
SGTM
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:
Might be worth cconsidering the points in "Contributing Extensions to Clang"
here: https://clang.llvm.org/get_involved.html
It'd be great if there were some numbers/metrics associated with the benefit,
ideally on some open source/commonly accessible codebase.
https://github.c
On Mon, Nov 13, 2023 at 4:28 AM Aaron Ballman
wrote:
> On Sun, Nov 12, 2023 at 11:42 PM David Blaikie wrote:
> >
> > Any chance this could/should reference the length by name, rather than
> by casts and pointer math? (so it's resilient to at least some changes to
> StringLiteral/StringRef?) Or i
Any chance this could/should reference the length by name, rather than by
casts and pointer math? (so it's resilient to at least some changes to
StringLiteral/StringRef?) Or is this the preferred way to write Natvis
visualizers, so they're resilient to missing debug info or something?
On Sun, Nov
dwblaikie wrote:
The words probably don't need to be short.
Interface BMI
Implementation BMI
Seem like fine, accurate terms. I guess we could say "BMInterface" and
"BMImplementation" but probably best to jus tgloss over "I" being "interface"
and have "interface BMI" and "implementation BMI"
dwblaikie wrote:
We probably (pretty sure) don't want to add a virtual dtor to SmallVector -
that'd add a vtable pointer, increasing the size in ways that are probably
unacceptable given the pervasive use of the data structure.
We should make the Impl dtor protected so it can't be polymorphica
dwblaikie wrote:
Please don't commit changes that have been sent for review, but have not been
reviewed.
https://github.com/llvm/llvm-project/pull/71031
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
dwblaikie wrote:
FWIW, we saw failures at Google (where, to the best of my knowledge, we aren't
using named modules at all) that look like this:
```
error: '#include ' attaches the declarations to the named module
'.get', which is not usually intended; consider moving that directive before
the
dwblaikie wrote:
> 2) always put DW_AT_const_value in DW_TAG_member.
My understanding is that this is not possible. Dependent initializer
expressions can't be evaluated in all cases - we're only allowed to evaluate
them in the places the language allows us to, otherwise we might produce the
w
dwblaikie wrote:
> That's true, if defined in a header, we'll emit a DW_TAG_variable for the
> constant in each compile unit the header is included in. GCC does do the
> right thing and only emit the definition DIE in a single CU. We should
> probably do the same. Though not sure at which leve
https://github.com/dwblaikie approved this pull request.
Few minor issues, but looks good to me.
(you metnioned somewhere an lldb issue I think with this patch when the value
is removed from the static member declaration inside the class? If that's a
problem - probably hold off on committing th
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int cexp
@@ -5883,6 +5907,18 @@ void CGDebugInfo::finalize() {
DBuilder.replaceTemporary(std::move(FwdDecl), cast(Repl));
}
+ for (auto const *VD : StaticDataMemberDefinitionsToEmit) {
+assert(VD->isStaticDataMember());
+
+if (auto It = DeclCache.find(VD); It != DeclCach
@@ -67,15 +67,15 @@ int C::a = 4;
// CHECK-NOT:size:
// CHECK-NOT:align:
// CHECK-NOT:offset:
-// CHECK-SAME: flags: DIFlagStaticMember,
-// CHECK-SAME: extraData: i1 true)
+// CHECK-SAME: flags: DIFlagStaticMemb
https://github.com/dwblaikie approved this pull request.
Looks great - thanks!
https://github.com/llvm/llvm-project/pull/70674
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
size report sounds generally OK - but there's a bunch of what look like
unrelated or strange results in there, perhaps they weren't compared at exactly
the same version? (like why did the apple_names size go down? How did the .text
and .debuG_line size change at all? )
https:
dwblaikie wrote:
> > > Should not we remove constant initializer from the type definition if we
> > > have a DW_TAG_variable with a DW_AT_const_value now?
> >
> >
> > Yep, +1 to this. This is where the type normalization benefit would come
> > from - no longer having this const value on the m
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
@@ -5935,3 +5918,29 @@ llvm::DINode::DIFlags
CGDebugInfo::getCallSiteRelatedAttrs() const {
return llvm::DINode::FlagAllCallsDescribed;
}
+
+llvm::DIExpression *
+CGDebugInfo::createConstantValueExpression(const clang::ValueDecl *VD,
+
dwblaikie wrote:
> Summing the size of all *.o files in my local debug Clang build increased by
> 0.7% with this patch
That's a bit significant. Any chance you could get a per-section
breakdown/growth on that? (& exact flags - is this with compressed debug info,
for instance? Or not?) I use `
dwblaikie wrote:
> Should not we remove constant initializer from the type definition if we have
> a DW_TAG_variable with a DW_AT_const_value now?
Yep, +1 to this. This is where the type normalization benefit would come from -
no longer having this const value on the member declaration, but on
@@ -0,0 +1,87 @@
+// RUN: %clangxx -target arm64-apple-macosx11.0.0 -g %s -emit-llvm -S -o - |
FileCheck --check-prefixes=CHECK %s
+
+enum class Enum : int {
+ VAL = -1
+};
+
+struct Empty {};
+
+constexpr auto func() { return 25; }
+
+struct Foo {
+static constexpr int cexp
@@ -0,0 +1,43 @@
+; RUN: llvm-as < %s -o %t0
+; RUN: llvm-dis %t0 -o - | FileCheck %s
+
dwblaikie wrote:
might be worth a comment describing the purpose of this test (some info from
the commit message, probably)
https://github.com/llvm/llvm-project/pull/68986
_
@@ -731,6 +731,29 @@ class MetadataLoader::MetadataLoaderImpl {
upgradeCULocals();
}
+ void cloneLocalTypes() {
+for (int I = MetadataList.size() - 1; I >= 0; --I) {
dwblaikie wrote:
any particular reason this iterates in reverse? Probably worth a
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/68986
___
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.
https://github.com/llvm/llvm-project/pull/68986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+ (Std->contain
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+ (Std->contain
@@ -6870,8 +6852,38 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
Args.AddLastArg(CmdArgs, options::OPT_finline_max_stacksize_EQ);
+ // FIXME: Find a better way to determine whether we are in C++20.
+ bool HaveCxx20 =
+ Std &&
+ (Std->contain
https://github.com/dwblaikie approved this pull request.
Some minor comments but generally looks good to me.
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def warn_attribute_und
@@ -3153,6 +3153,12 @@ def err_invalid_branch_protection_spec : Error<
"invalid or misplaced branch protection specification '%0'">;
def warn_unsupported_branch_protection_spec : Warning<
"unsupported branch protection specification '%0'">,
InGroup;
+def warn_attribute_und
dwblaikie wrote:
> ```c++
> struct A {
> short a1;
> short a2;
> };
>
> struct B {
> [[clang::preferred_type(A)]] unsigned b1 : 32 = 0x000F'000C;
> };
>
> int main()
> {
> B b;
> return b.b1;
> }
> ```
An example where the layout doesn't match the normal struct layout might be
m
dwblaikie wrote:
> > FWIW, I think we also saw, internally at Google, some significant and
> > surprising (growth in sections, like .debug_loclists and
> > .debug_gnu_pubnames/types) that were a bit surprising/not what I'd have
> > expected of the original committed/reverted patch.
> > Could y
dwblaikie wrote:
> > I still support disabling delayed template parsing by default in all
> > configurations. Ultimately, this feature is a source of bugs, and we should
> > start the clock on its deprecation and removal. This, of course, involves
> > real work, and I haven't allocated any tim
https://github.com/dwblaikie approved this pull request.
Looks good.
I wonder how this happened in the first place - that the author of the
diagnostic was already adding the 3rd parameter into the arguments but there
was no `%2` in the diagnostic text/template...
It'd be great if we had some
dwblaikie wrote:
Does MSVC have the delayed template parsing effects when using modules? If not,
perhaps we should just disable the flag/not allow it to be composed together?
https://github.com/llvm/llvm-project/pull/69431
___
cfe-commits mailing list
@@ -62,7 +62,7 @@ def err_ast_file_out_of_date : Error<
"%select{PCH|module|AST}0 file '%1' is out of date and "
"needs to be rebuilt%select{|: %3}2">, DefaultFatal;
def err_ast_file_invalid : Error<
- "file '%1' is not a valid precompiled %select{PCH|module|AST}0 file">,
dwblaikie wrote:
> Wouldn't it be better to go the other way around? i.e. have a
> `[[clang::compressed_bitfield]]` (or whatever) which influences the ABI, so
> it's possible to do stuff like
>
> ```c++
> [[clang::compressed_bitfield]] bool IsSomething : 1;
> [[clang::compressed_bitfield]] MyE
dwblaikie wrote:
Seems a bit unfortunate/bit of a heavyweight workaround - but I don't
fundamentally object if @AaronBallman or co are OK with the new attribute for
this.
https://github.com/llvm/llvm-project/pull/69104
___
cfe-commits mailing list
cf
dwblaikie wrote:
> This is useful when user is forced to use the same type for all bitfields in
> a class to get better [layout](https://godbolt.org/z/ovWqzqv9x) and
> [codegen](https://godbolt.org/z/bdoqvz9e6) from MSVC
Does this issue not apply to other platforms? (I didn't think you could
dwblaikie wrote:
FWIW, I think we also saw, internally at Google, some significant and
surprising (growth in sections, like .debug_loclists and
.debug_gnu_pubnames/types) that were a bit surprising/not what I'd have
expected of the original committed/reverted patch.
Could you run a clang buil
@@ -2028,6 +2030,8 @@ example:
This attribute suggests that optimization passes and code generator passes
should make choices that try to preserve debug info without significantly
degrading runtime performance.
+This attribute is incompatible with the ``minsize`
@@ -1085,6 +1085,7 @@ The integer codes are mapped to well-known attributes as
follows.
* code 77: ``elementtype``
* code 78: ``disable_sanitizer_instrumentation``
* code 79: ``nosanitize_bounds``
+* code 88: ``optdebug``
dwblaikie wrote:
This could/should be
https://github.com/dwblaikie approved this pull request.
looks good - a few bits should be committed separately from this change, so
please do those first and then commit this change
https://github.com/llvm/llvm-project/pull/66632
___
cfe-commits mail
https://github.com/dwblaikie edited
https://github.com/llvm/llvm-project/pull/66632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,158 @@
+//===- raw_ostream_proxy.h - Proxies for raw output streams -*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
https://github.com/dwblaikie approved this pull request.
https://github.com/llvm/llvm-project/pull/68501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
*shrug* I guess it's OK.
https://github.com/llvm/llvm-project/pull/68501
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
dwblaikie wrote:
This doesn't seem all that useful/important to me - a user can move the body of
the function into an implementation unit rather than putting it in the
interface unit and marking it noinline, right? This is the same recommendation
we'd make if someone wrote a complex function d
201 - 300 of 1381 matches
Mail list logo
