Author: Richard Smith
Date: 2021-10-06T15:13:05-07:00
New Revision: 7063b76b02484f93104f1c79496ad216b9bf5b87
URL:
https://github.com/llvm/llvm-project/commit/7063b76b02484f93104f1c79496ad216b9bf5b87
DIFF:
https://github.com/llvm/llvm-project/commit/7063b76b02484f93104f1c79496ad216b9bf5b87.diff
Author: Richard Smith
Date: 2021-10-06T15:13:06-07:00
New Revision: 141df744564822b8d8250fe1bcec15cdbd5f213e
URL:
https://github.com/llvm/llvm-project/commit/141df744564822b8d8250fe1bcec15cdbd5f213e
DIFF:
https://github.com/llvm/llvm-project/commit/141df744564822b8d8250fe1bcec15cdbd5f213e.diff
Author: Richard Smith
Date: 2021-10-08T13:54:01-07:00
New Revision: 7ac308fb8f283249b89851702aa07f3ed9ac86d4
URL:
https://github.com/llvm/llvm-project/commit/7ac308fb8f283249b89851702aa07f3ed9ac86d4
DIFF:
https://github.com/llvm/llvm-project/commit/7ac308fb8f283249b89851702aa07f3ed9ac86d4.diff
Author: Richard Smith
Date: 2021-10-08T14:25:17-07:00
New Revision: 64e9044ea43d2cee2a927bf221c5395a40a5e2fd
URL:
https://github.com/llvm/llvm-project/commit/64e9044ea43d2cee2a927bf221c5395a40a5e2fd
DIFF:
https://github.com/llvm/llvm-project/commit/64e9044ea43d2cee2a927bf221c5395a40a5e2fd.diff
Author: Richard Smith
Date: 2021-10-08T18:46:01-07:00
New Revision: 222305d6ff6f6d156145d7de4f06d1c368383e41
URL:
https://github.com/llvm/llvm-project/commit/222305d6ff6f6d156145d7de4f06d1c368383e41
DIFF:
https://github.com/llvm/llvm-project/commit/222305d6ff6f6d156145d7de4f06d1c368383e41.diff
Author: Richard Smith
Date: 2021-10-08T19:59:42-07:00
New Revision: 7eae8c6e62b2a91e71aade19324b9d2242bcb4ab
URL:
https://github.com/llvm/llvm-project/commit/7eae8c6e62b2a91e71aade19324b9d2242bcb4ab
DIFF:
https://github.com/llvm/llvm-project/commit/7eae8c6e62b2a91e71aade19324b9d2242bcb4ab.diff
On Wed, 15 Sept 2021 at 13:52, David Blaikie wrote:
> On Tue, Sep 14, 2021 at 10:04 AM Richard Smith
> wrote:
>
>> On Mon, 13 Sept 2021 at 19:24, David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> Author: David Blaikie
>>> Date: 2021-09-13T19:17:05-07:00
>>> New Rev
Author: Richard Smith
Date: 2021-10-11T16:37:39-07:00
New Revision: 25b3370ff25f7a21f71e0dc6c4d7624d52cab604
URL:
https://github.com/llvm/llvm-project/commit/25b3370ff25f7a21f71e0dc6c4d7624d52cab604
DIFF:
https://github.com/llvm/llvm-project/commit/25b3370ff25f7a21f71e0dc6c4d7624d52cab604.diff
Author: Richard Smith
Date: 2021-10-14T20:55:51-07:00
New Revision: effbf0bdd039237542ac5e9afe1f23c9386010e2
URL:
https://github.com/llvm/llvm-project/commit/effbf0bdd039237542ac5e9afe1f23c9386010e2
DIFF:
https://github.com/llvm/llvm-project/commit/effbf0bdd039237542ac5e9afe1f23c9386010e2.diff
On Sun, 17 Oct 2021 at 04:58, Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Aaron Ballman
> Date: 2021-10-17T07:54:48-04:00
> New Revision: 2edb89c746848c52964537268bf03e7906bf2542
>
> URL:
> https://github.com/llvm/llvm-project/commit/2edb89c746848c52964537268bf03
On Mon, 18 Oct 2021 at 12:48, Aaron Ballman wrote:
> On Mon, Oct 18, 2021 at 3:33 PM Richard Smith
> wrote:
> >
> > On Sun, 17 Oct 2021 at 04:58, Aaron Ballman via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >>
> >>
> >> Author: Aaron Ballman
> >> Date: 2021-10-17T07:54:48-04:00
> >> N
On Mon, 18 Oct 2021 at 12:56, Aaron Ballman wrote:
> On Mon, Oct 18, 2021 at 3:52 PM Richard Smith
> wrote:
> >
> > On Mon, 18 Oct 2021 at 12:48, Aaron Ballman
> wrote:
> >>
> >> On Mon, Oct 18, 2021 at 3:33 PM Richard Smith
> wrote:
> >> >
> >> > On Sun, 17 Oct 2021 at 04:58, Aaron Ballman v
Author: Richard Smith
Date: 2021-08-24T17:03:06-07:00
New Revision: df7b6b91422dbdbdb1de66fd865853e78ea3e5d2
URL:
https://github.com/llvm/llvm-project/commit/df7b6b91422dbdbdb1de66fd865853e78ea3e5d2
DIFF:
https://github.com/llvm/llvm-project/commit/df7b6b91422dbdbdb1de66fd865853e78ea3e5d2.diff
Author: Richard Smith
Date: 2021-08-24T19:53:44-07:00
New Revision: cd4d6d718b2e51ed830a28d01d765da2a220afd3
URL:
https://github.com/llvm/llvm-project/commit/cd4d6d718b2e51ed830a28d01d765da2a220afd3
DIFF:
https://github.com/llvm/llvm-project/commit/cd4d6d718b2e51ed830a28d01d765da2a220afd3.diff
Author: Richard Smith
Date: 2021-08-25T11:36:11-07:00
New Revision: ea1c01dde03b45e0b33d3883147d3b4fb489978c
URL:
https://github.com/llvm/llvm-project/commit/ea1c01dde03b45e0b33d3883147d3b4fb489978c
DIFF:
https://github.com/llvm/llvm-project/commit/ea1c01dde03b45e0b33d3883147d3b4fb489978c.diff
Author: Richard Smith
Date: 2021-09-01T18:00:07-07:00
New Revision: 6eda66b0a9f793c65852aa94430ae9bd891bcf63
URL:
https://github.com/llvm/llvm-project/commit/6eda66b0a9f793c65852aa94430ae9bd891bcf63
DIFF:
https://github.com/llvm/llvm-project/commit/6eda66b0a9f793c65852aa94430ae9bd891bcf63.diff
On Mon, 13 Sept 2021 at 19:24, David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: David Blaikie
> Date: 2021-09-13T19:17:05-07:00
> New Revision: 2bd84938470bf2e337801faafb8a67710f46429d
>
> URL:
> https://github.com/llvm/llvm-project/commit/2bd84938470bf2e337801faafb8a
Author: Richard Smith
Date: 2021-09-15T15:43:02-07:00
New Revision: 699da98739b0f88c27f75adbe8295c7e1dfd0188
URL:
https://github.com/llvm/llvm-project/commit/699da98739b0f88c27f75adbe8295c7e1dfd0188
DIFF:
https://github.com/llvm/llvm-project/commit/699da98739b0f88c27f75adbe8295c7e1dfd0188.diff
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/96573
Explicitly describe how the Clang builtin works, given that it's not exactly
the same as GCC's builtin of the same name -- but is drop-in compatible.
Fixes #95635.
>From 3394d999888087535db9ede87668829eddc33ac
@@ -5368,16 +5368,85 @@ The ``#pragma comment(lib, ...)`` directive is
supported on all ELF targets.
The second parameter is the library name (without the traditional Unix prefix
of
``lib``). This allows you to provide an implicit link of dependent libraries.
-Evaluating Ob
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/96573
>From 3394d999888087535db9ede87668829eddc33ac7 Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Mon, 24 Jun 2024 15:52:18 -0700
Subject: [PATCH 1/2] Add documentation for `__builtin_object_size`.
Explicitly d
https://github.com/zygoloid approved this pull request.
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/93115
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
@@ -4772,7 +4772,8 @@ class CodeGenFunction : public CodeGenTypeCache {
/// Build all the stores needed to initialize an aggregate at Dest with the
/// value Val.
zygoloid wrote:
This comment looks out of date.
https://github.com/llvm/llvm-project/pull/9
@@ -1392,7 +1392,8 @@ class CXXRecordDecl : public RecordDecl {
bool allowConstDefaultInit() const {
return !data().HasUninitializedFields ||
!(data().HasDefaultedDefaultConstructor ||
- needsImplicitDefaultConstructor());
+ needsImplici
@@ -1336,75 +1336,56 @@ static llvm::Value *CreateCoercedLoad(Address Src,
llvm::Type *Ty,
return CGF.Builder.CreateLoad(Tmp);
}
-// Function to store a first-class aggregate into memory. We prefer to
-// store the elements rather than the aggregate to be more friendly to
zygoloid wrote:
> I have a question about the "sub-object" part. Do we attempt to discover the
> sub-object past any casting?
Good question. I'm going to merge this PR, so I've filed #96737 for this
ongoing discussion.
https://github.com/llvm/llvm-project/pull/96573
__
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/96573
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
> Discussion on the WG14 reflectors suggested that the qualifiers should still
> be stripped from the type of the controlling expression; the standard should
> be corrected to make this more clear.
Does WG14 think we're right to produce a qualified rvalue in this case? Another
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/97128
The mangling compatibility being tested here changed between Clang 17 and 18,
not between 16 and 17, so change the "old" version to 17.
As requested by @ahatanak in [post-commit
review](https://github.com/llvm
zygoloid wrote:
See https://github.com/llvm/llvm-project/issues/58754#issuecomment-2354048986
-- this introduces a miscompile by producing comparison results at compile time
that differ from the results at runtime. Please can this be reverted?
https://github.com/llvm/llvm-project/pull/106733
_
zygoloid wrote:
Specifically: we do perform address comparisons between these strings, so the
address is significant. And we can have identical string content but different
types:
- for types whose name involves anything with internal linkage
- for types with hidden visibility
- when loading a
zygoloid wrote:
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-rtti and
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#typeid in the ABI require
the type name string to be globally unique, and some `std::type_info`
implementations rely on that. You might be able to do this for so
https://github.com/zygoloid approved this pull request.
Thanks!
https://github.com/llvm/llvm-project/pull/111446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Can we remove `getAddressOfPointer` instead?. Where is it being used?
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
@@ -19,8 +19,10 @@ namespace usage_invalid {
namespace usage_ok {
struct IntRef { int *target; };
+ const int *defaultparam(const int &def1 [[clang::lifetimebound]] = 0); //
#def1
int &refparam(int ¶m [[clang::lifetimebound]]);
int &classparam(IntRef param [[clang::l
https://github.com/zygoloid commented:
Thanks, this seems reasonable.
https://github.com/llvm/llvm-project/pull/112047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/112047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -532,6 +533,11 @@ static void
visitLocalsRetainedByReferenceBinding(IndirectLocalPath &Path,
}
} while (Init != Old);
+ if (auto *DAE = dyn_cast(Init)) {
+Path.push_back({IndirectLocalPathEntry::DefaultArg, DAE, DAE->getParam()});
+Init = DAE->getExpr();
+
https://github.com/zygoloid commented:
Please can you also add tests for the case where the default argument is a
pointer, eg:
```c++
using T = int[];
int *f([[clang::lifetimebound]] int *p = T{1, 2, 3});
int *p = f();
```
I expect that won't be caught, and you'll need to make a similar change t
zygoloid wrote:
> I expect that won't be caught, and you'll need to make a similar change to
> `visitLocalsRetainedByInitializer` to handle it.
Actually, maybe the best thing would be to change `visitFunctionCallArguments`
to step over `CXXDefaultArgExpr` in `Args`. That should cover both case
zygoloid wrote:
> But, I have a question: now that it has ensured the uniqueness of typeinfo's
> address, why does the implementation still compare the type equality by the
> address of type name string?
The uniqueness of the address of the `type_info` object itself is not
guaranteed. The rea
zygoloid wrote:
Should this have `-fclang-abi-compat` support?
https://github.com/llvm/llvm-project/pull/110247
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -119,6 +119,16 @@ namespace cwg109 { // cwg109: yes
};
}
+namespace cwg110 { // cwg110: 2.8
+template
+void f();
+
+class f;
+
+template
+void f(int);
+} // namespace cwg110
zygoloid wrote:
It'd be nice to also check that `class f` works here, and that
zygoloid wrote:
> How about:
> [...]
Yeah, I think that fixes it. For me that looks a lot less simple than using a
union, but it is nice to have only a single implementation. I'd be fine with
going in that direction.
For CHERI, can we assume that the least-significant byte of the pointer
rep
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/112806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
Closing in favour of #112927.
https://github.com/llvm/llvm-project/pull/112806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
> Doesn't it change ABI, though?
Only on platforms where it didn't work at all before.
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
zygoloid wrote:
> But yes, the short answer is that the code as written should work on Morello
> and CHERI-RISC-V.
Great, thanks.
> > > The std::launder may be unnecessary
> >
> >
> > Formally I think it's correct and necessary for the pointer and integer
> > case because an array element a
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -326,45 +328,65 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ static constexpr size_t DataSize = std::max(sizeof(uint64_t), sizeof(T *))
https://github.com/zygoloid approved this pull request.
One style nit, otherwise looks good, thanks!
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
zygoloid wrote:
I've been pondering this. On the one hand, people switching from the
`cl.exe`-compatible driver to the GCC-compatible driver might want the MSVC
interpretation of the path flags. On the other hand, people enabling
`-fms-compatibility` to accept code written against MSVC in a di
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
zygoloid wrote:
> > Can we remove `getAddressOfPointer` instead?. Where is it being used?
>
> It is used in `VarDecl::getInitAddress()` in Decl.cpp. It looks like it is
> used indirectly by the StmtIterator
And that in turn is used in `StmtIterator`, and indeed we can end up *storing
through*
zygoloid wrote:
This choice seems like a question of how the driver's command line is
interpreted, rather than a language mode, so I wonder if it makes sense for it
to consider `-fms-compatibility` at all or whether this should just be based on
the driver mode. Do you have rationale for this a
@@ -321,50 +322,87 @@ class ExternalASTSource : public
RefCountedBase {
/// external AST source itself.
template
struct LazyOffsetPtr {
- /// Either a pointer to an AST node or the offset within the
- /// external AST source where the AST node can be found.
- ///
- /// If
zygoloid wrote:
#112806 should address this without narrowing the field to 32 bits.
https://github.com/llvm/llvm-project/pull/111995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/112806
Don't try to read the `uint64_t` stored in `LazyOffsetPtr` as a `T*` via
`getAddressOfPointer`. This violates aliasing rules and doesn't work at all on
big-endian 64-bit systems where the pointer is stored in th
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/112806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
> > This violates aliasing rules and doesn't work at all on big-endian 64-bit
> > systems where the pointer is stored in the second four bytes of the
> > uint64_t.
>
> Your sizes aren't correct in the description here. This issue occurs on big
> endian 32-bit systems,
Yeah, s
zygoloid wrote:
> > > #112806 should address this without narrowing the field to 32 bits.
> >
> >
> > As does [#111995
> > (comment)](https://github.com/llvm/llvm-project/pull/111995#discussion_r1805329590),
> > with less code and more generality
>
> I prefer this solution too.
That solutio
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/111343
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid commented:
Hmm. Looking at https://reviews.llvm.org/D20348 it seems like `unnamed_addr`
and `local_unnamed_addr` don't just permit merging, but also cloning of the
global (so that the same global could have different addresses in different
modules). Cloning wouldn't
@@ -4097,6 +4096,7 @@ llvm::Constant *ItaniumRTTIBuilder::BuildTypeInfo(
// And the name.
llvm::GlobalVariable *TypeName = GetAddrOfTypeName(Ty, Linkage);
llvm::Constant *TypeNameField;
+ llvm::GlobalValue::UnnamedAddr Scope;
zygoloid wrote:
`Scope` isn
zygoloid wrote:
> unnamed_addr doesn't allow cloning; there's no way to make it work in a
> reasonable way even if we wanted it. See, for example, #32127 .
OK. The LangRef is very vague on its semantics, would be nice to get that
clarified by someone who knows the intent.
Is the same true for
zygoloid wrote:
@luxufan I think we may need changes on the LLVM side before we can make
progress here -- either to clarify what `unnamed_addr` is intended to mean, or
perhaps to split it into separate attributes for cloning and merging.
But before we go down that path, this PR doesn't describ
@@ -1703,7 +1703,7 @@ namespace {
bool checkNullPointerDiagnosingWith(const GenDiagType &GenDiag) {
if (Designator.Invalid)
return false;
- if (IsNullPtr) {
+ if (getLValueBase().isNull()) {
zygoloid wrote:
Why was the old check not
@@ -1703,7 +1703,7 @@ namespace {
bool checkNullPointerDiagnosingWith(const GenDiagType &GenDiag) {
if (Designator.Invalid)
return false;
- if (IsNullPtr) {
+ if (getLValueBase().isNull()) {
zygoloid wrote:
Oh, I see. We're adjustin
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/114857
None
>From 25047a9f9b8b961451bef0d0c526944d17ffe9d7 Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Mon, 4 Nov 2024 11:27:46 -0800
Subject: [PATCH 1/2] Don't redundantly specify the default template argumen
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/116100
Fixes #116096.
>From 885c95fcf03f9ab89b7d445ee758c69c77333567 Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 13 Nov 2024 12:09:01 -0800
Subject: [PATCH] Document that the lifetime of the caller-side `
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 1/2] Implement current CWG direction for string literal
compari
https://github.com/zygoloid ready_for_review
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zygoloid created
https://github.com/llvm/llvm-project/pull/109208
Track the identity of each string literal object produced by evaluation
with a global version number. Accept comparisons between literals of the
same version, and between literals of different versions that cann
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 1/3] Implement current CWG direction for string literal
compari
https://github.com/zygoloid edited
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
@fsfod Can you update the first comment to describe the overall purpose of this
change? That seems pretty central to understanding whether we want this, and if
so, whether this looks like the right set of annotations.
https://github.com/llvm/llvm-project/pull/109702
___
zygoloid wrote:
I believe all the feedback has been addressed, and plan to merge in 24 hours if
there are no further comments.
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
zygoloid wrote:
In @sdkrystian's example, does the use of `A<1>::B` within `A<0>::B` cause
an implicit instantiation to take place? I would have expected that no implicit
instantiation takes place at that point because `A<1>::B` is a dependent
type. I would expect that the specialization of `A
https://github.com/zygoloid closed
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1214,3 +1216,25 @@ namespace test61 {
// CHECK-LABEL: @_ZN6test611fINS_1XEEEvNT_1Y1aENS3_1bE
template void f(int, int);
}
+
+namespace test62 {
+namespace A {
+
+class VBase {
+ public:
+ virtual ~VBase() {};
+};
+
+struct Wrap {};
+
+template
+class Impl : public vir
zygoloid wrote:
> Do we need an ABI flag guarding against the change as well?
Yeah, I think this change should respect `-fclang-abi-compat`.
https://github.com/llvm/llvm-project/pull/109970
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
zygoloid wrote:
I found this:
https://fuchsia.googlesource.com/third_party/github.com/fmtlib/fmt/+/refs/heads/upstream/main/include/fmt/base.h#2664
Note that this is passing `s` separately both to `parse_format_string` and to
`checker`. Here, `s` is a lambda that implicitly converts to a strin
zygoloid wrote:
I've filed a fmtlib bug: https://github.com/fmtlib/fmt/issues/4177
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zygoloid wrote:
That backtrace doesn't match the fmtlib code available from their official
repository. Where can I find the code you're building?
https://github.com/llvm/llvm-project/pull/109208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -74,6 +74,22 @@ C++ Specific Potentially Breaking Changes
template
void f();
+- During constant evaluation, comparisons between different evaluations of the
+ same string literal are now correctly treated as non-constant, and
comparisons
+ between string literal
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 01/11] Implement current CWG direction for string literal
compa
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 01/14] Implement current CWG direction for string literal
compa
@@ -8573,7 +8661,10 @@ class LValueExprEvaluator
bool VisitMaterializeTemporaryExpr(const MaterializeTemporaryExpr *E);
bool VisitCompoundLiteralExpr(const CompoundLiteralExpr *E);
bool VisitMemberExpr(const MemberExpr *E);
- bool VisitStringLiteral(const StringLiteral *
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 01/13] Implement current CWG direction for string literal
compa
zygoloid wrote:
> I'm happy once SOME level of solution for the index-starting-value is done
> (`NextStringLiteralVersion=rand()` 🤡). I think the avoided collisions is
> worth a touch of effort, but not much more.
Um. So. I added a test for this before I started working on a fix, and ... the
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 01/12] Implement current CWG direction for string literal
compa
@@ -108,22 +108,16 @@ constexpr auto p2 = "test2";
constexpr bool b1 = foo(p1) == foo(p1);
static_assert(b1);
-constexpr bool b2 = foo(p1) == foo(p2); // ref-error {{must be initialized by
a constant expression}} \
-// ref-note {{compar
@@ -2142,11 +2150,91 @@ static const ValueDecl *GetLValueBaseDecl(const LValue
&LVal) {
return LVal.Base.dyn_cast();
}
-static bool IsLiteralLValue(const LValue &Value) {
- if (Value.getLValueCallIndex())
+// Information about an LValueBase that is some kind of string.
+st
zygoloid wrote:
> I worry about string literals in vague-linkage entities, because the
> "version" of the string literal which is referred to from an
> inline-function/variable at runtime may not actually be the same version of
> the string literal seen in the current compilation -- at runtime
https://github.com/zygoloid updated
https://github.com/llvm/llvm-project/pull/109208
>From 81193568c17a89f6cf42f43a82fb1fbf0f90184d Mon Sep 17 00:00:00 2001
From: Richard Smith
Date: Wed, 18 Sep 2024 21:59:56 +
Subject: [PATCH 01/15] Implement current CWG direction for string literal
compa
@@ -704,6 +704,15 @@ ItaniumMangleContextImpl::getEffectiveDeclContext(const
Decl *D) {
return D->getLexicalDeclContext()->getRedeclContext();
}
+ if (const auto *FTD = dyn_cast(D)) {
+// Member-like constrained friends are mangled as if they were members of
+
@@ -693,7 +693,7 @@ ItaniumMangleContextImpl::getEffectiveDeclContext(const
Decl *D) {
if (VD->isExternC())
return getASTContext().getTranslationUnitDecl();
- if (const auto *FD = D->getAsFunction()) {
+ if (const auto *FD = dyn_cast(D)) {
zygoloi
4001 - 4100 of 4285 matches
Mail list logo
