https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/141779
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
Thanks! Ironically, ReleaseNotes.rst is where I started my patch, but I forgot
to actually update it :)
https://github.com/llvm/llvm-project/pull/141779
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/141779
>From ca8e6ce98db72d3b37a26b59bda5ed4c8b7a6ed5 Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Wed, 28 May 2025 16:35:16 +0200
Subject: [PATCH 1/2] [clang] Rename -Wdeprecated-switch-case to
-Wdeprecated-decl
https://github.com/zmodem created
https://github.com/llvm/llvm-project/pull/141779
To make it more clear that it's a subset of -Wdeprecated-declarations.
Follow-up to #138562
>From ca8e6ce98db72d3b37a26b59bda5ed4c8b7a6ed5 Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Wed, 28 May 2025 16:
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/138562
>From e221ba3b0f7b08bcfc56bf75f7505265c332637d Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Mon, 5 May 2025 20:24:15 +0200
Subject: [PATCH 1/9] [Sema] Warn about omitting deprecated enumerator in
switch
T
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/138562
>From e221ba3b0f7b08bcfc56bf75f7505265c332637d Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Mon, 5 May 2025 20:24:15 +0200
Subject: [PATCH 1/8] [Sema] Warn about omitting deprecated enumerator in
switch
T
@@ -6009,6 +6009,8 @@ def note_not_found_by_two_phase_lookup : Note<"%0 should
be declared prior to th
def err_undeclared_use : Error<"use of undeclared %0">;
def warn_deprecated : Warning<"%0 is deprecated">,
InGroup;
+def warn_deprecated_switch_case : Warning<"%0 is depr
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/138562
>From e221ba3b0f7b08bcfc56bf75f7505265c332637d Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Mon, 5 May 2025 20:24:15 +0200
Subject: [PATCH 1/7] [Sema] Warn about omitting deprecated enumerator in
switch
T
zmodem wrote:
Thanks Aaron, that's a good example.
This is a pickle; it doesn't seem like there's an obviously Right Solution(tm)
here.
I think we're agreeing on the first part, that unhandled deprecated enums
should trigger the "not covered" warning.
Some users will prefer to handle that wi
zmodem wrote:
Ours too :-)
https://github.com/llvm/llvm-project/pull/140859
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> Now we have a special Wdeprecated-declarations carveouts for switches, but if
> you unpack the switch into if / else chain comparisons, you get deprecation
> warnings.
Agreed, that it is a bit inconsistent. There is prior art though:
ba87c626f9b7c48a79673d3fd682c2a1e80a7200 ma
@@ -6767,6 +6767,9 @@ class Sema final : public SemaBase {
};
std::optional DelayedDefaultInitializationContext;
+/// Whether evaluating an expression for a switch case label.
zmodem wrote:
Done.
https://github.com/llvm/llvm-project/pull/138562
_
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/138562
>From e221ba3b0f7b08bcfc56bf75f7505265c332637d Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Mon, 5 May 2025 20:24:15 +0200
Subject: [PATCH 1/6] [Sema] Warn about omitting deprecated enumerator in
switch
T
zmodem wrote:
> If we add lifetimes to it, middle end passes may assume promise dead after
> lifetime.end, leading to mis-optimizations.
It sounds like the issue is that we emit *incorrect* lifetime intrinsics for
it, not the lifetime intrinsics itself.
> Here is a example
Was that generated
zmodem wrote:
> I think '/Fo' is basically '-o'. Its semantic is to specify the path to the
> output file.
No, `/Fo` is for object files, `/Fe` for the executable, `/Fp` for pch file etc.
> So if now clang-cl can accept '-o' [...]
It works in general in clang-cl. I guess we'd have to double c
zmodem wrote:
Sorry, I don't remember seeing that discussion, and I'm probably missing lots
of modules context. As a counter argument, clang-cl uses `/Yc` and `/Fp` to
generate PCH files, to match MSVC's interface although the file format is
different.
More importantly, it feels like we're be
zmodem wrote:
> @zmodem given how important this it, I hope we can make this for clang21.
> Thanks!
I'm just a reviewer here, and I still find the patch very confusing.
And taking a step back, the whole point of clang-cl is to provide a cl.exe
compatible interface to clang. I presume cl.exe d
zmodem wrote:
I've added suppression of deprecated values in case expressions. Please take
another look!
https://github.com/llvm/llvm-project/pull/138562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/138562
Rate limit · GitHub
body {
background-color: #f6f8fa;
color: #24292e;
font-family: -apple-system,BlinkMacSystemFont,Segoe
UI,Helvetica,Arial,sans-se
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/138562
>From e221ba3b0f7b08bcfc56bf75f7505265c332637d Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Mon, 5 May 2025 20:24:15 +0200
Subject: [PATCH 1/4] [Sema] Warn about omitting deprecated enumerator in
switch
T
zmodem wrote:
This is very interesting!
Initially I also assumed this was about Edit&Continue. As users may have the
same idea, I'd suggest adding `DocBrief`s to the new Clang options, and a
comment at the top of llvm/lib/CodeGen/WindowsHotPatch.cpp that explain in more
detail what they do.
zmodem wrote:
Thanks for the explanation. I'm not pushing back here, just trying to
understand.
https://github.com/llvm/llvm-project/pull/139061
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
zmodem wrote:
I don't know all the background here, so apologies if this is a silly question,
but we have some code that's checking:
```
static_assert(__is_trivially_relocatable(std::pair));
```
which now triggers a -Wdeprecated-builtins warning.
But if I switch to `__builtin_is_cpp_trivially
zmodem wrote:
It found something :-)
https://github.com/sqlite/sqlite/blob/eb55814c62adecfcb586263c11e60fb24973b1ef/ext/misc/vfstrace.c#L584
(Reported in https://sqlite.org/forum/forumpost/744dffb4ca)
https://github.com/llvm/llvm-project/pull/133653
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/138741
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
I wonder if we should also do something special about the
`-Wdeprecated-declarations` diagnostic in switches.
If the user fixes the -Wswitch / -Wreturn-type warnings from `testSwitchFour`
the natural way:
```
int testSwitchFour(enum SwitchFour e) {
switch (e) {
case Red:
zmodem wrote:
> Fly-by comment: I drafted the following alternative comment in another
> thread. Please feel free to disregard as I don't know the tone and style of
> comments in these files. (But I appreciate your consideration for the
> contents in the message I'd like to see!)
>
> ```
>
@@ -15,7 +15,7 @@ enum SwitchTwo {
};
void testSwitchTwo(enum SwitchTwo st) {
- switch (st) {} // expected-warning{{enumeration values 'Vim' and 'Emacs' not
handled in switch}}
+ switch (st) {} // expected-warning{{enumeration values 'Ed', 'Vim' and
'Emacs' not handled in
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/138562
>From e221ba3b0f7b08bcfc56bf75f7505265c332637d Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Mon, 5 May 2025 20:24:15 +0200
Subject: [PATCH 1/2] [Sema] Warn about omitting deprecated enumerator in
switch
T
https://github.com/zmodem created
https://github.com/llvm/llvm-project/pull/138562
This undoes part of 3e4e3b17c14c15c23c0ed18ca9165b42b1b13ae3 which added the
"Omitting a deprecated constant is ok; it should never materialize." logic.
That seems wrong: deprecated means the enumerator is likel
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/138507
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/138343
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> this causes a `-Wmicrosoft-goto` warning on [...]
Sent https://github.com/llvm/llvm-project/pull/138507 for this.
https://github.com/llvm/llvm-project/pull/138009
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
https://github.com/zmodem created
https://github.com/llvm/llvm-project/pull/138507
Follow-up to #138009 which added diagnostics for "jump past initialization" in
C mode, in which case they're not an MS extension.
Rate limit · GitHub
body {
backgr
@@ -103,3 +103,46 @@ static_assert(_Generic(typeof(overload_func(&ptr0)), int :
1, default : 0));
static_assert(_Generic(typeof(overload_func(&valid0)), float : 1, default :
0));
void func(int array[__ptrauth(VALID_DATA_KEY) 10]); // expected-error
{{'__ptrauth' qualifier o
https://github.com/zmodem edited
https://github.com/llvm/llvm-project/pull/136783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem commented:
Looks reasonable to my non-expert eyes
https://github.com/llvm/llvm-project/pull/136783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -95,6 +95,8 @@ struct CopiedTypeVisitor {
return asDerived().visitARCWeak(FT, std::forward(Args)...);
case QualType::PCK_Struct:
return asDerived().visitStruct(FT, std::forward(Args)...);
+case QualType::PCK_PtrAuth:
zmodem wrote:
style
zmodem wrote:
I too had trouble understanding this change based on the description. Could you
give a concrete example of how mingw and msvc disagree on where to put the
attribute, and explain how this pr changes things?
Taking a step back, how will this simplify libc++'s visibility annotations
Author: Hans Wennborg
Date: 2025-04-22T11:11:33+02:00
New Revision: e12681ae733e8341c161534d4d4de2611573b616
URL:
https://github.com/llvm/llvm-project/commit/e12681ae733e8341c161534d4d4de2611573b616
DIFF:
https://github.com/llvm/llvm-project/commit/e12681ae733e8341c161534d4d4de2611573b616.diff
zmodem wrote:
Thanks! I'll go ahead and push the button. Hope you feel better soon!
https://github.com/llvm/llvm-project/pull/135611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/135611
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> This causes the whole libc++ CI to fail, since we're not building against a
> compiler built from current trunk.
Can you provide an example, such as a link to a failing build, or an
explanation of the failure? I found
https://buildkite.com/llvm-project/libcxx-ci/builds?created
zmodem wrote:
> Thanks! Unfortunately it looks like the fix introduced a regression of
> #134265 on Windows. Repro:
(For reference, this is https://crbug.com/41261 on our side.)
The "deleted operator delete[]" is coming from here:
https://source.chromium.org/chromium/chromium/src/+/main:v
zmodem wrote:
Smaller repro:
```
$ cat /tmp/a.ii
class Trans_NS_cppgc_GarbageCollected {
void operator delete[](void *);
};
struct ScriptWrappable : Trans_NS_cppgc_GarbageCollected {
virtual ~ScriptWrappable();
};
struct __declspec(dllexport) ContentIndexEvent : ScriptWrappable {
Content
zmodem wrote:
We're seeing crashes that bisect to this change. Here is a reproducer:
https://crbug.com/410001969#comment3
I'll see if I can get something more reduced as well.
https://github.com/llvm/llvm-project/pull/134357
___
cfe-commits mailing l
zmodem wrote:
> I think moving it to -Wextra may be a more palatable approach. What do others
> think?
Sounds good to me, and I think James makes a good argument.
Does that actually help LLVM and libc++ though? I think at least LLVM does
enable -Wextra.
https://github.com/llvm/llvm-project/p
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/133265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem approved this pull request.
I didn't look at the original patch, but the fix and test update lgtm.
https://github.com/llvm/llvm-project/pull/133451
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
https://github.com/zmodem approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/133265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7976,6 +7976,8 @@ void
CodeGenModule::requireVectorDestructorDefinition(const CXXRecordDecl *RD) {
auto *NewFn = llvm::Function::Create(
cast(VDEntry->getValueType()),
llvm::Function::ExternalLinkage, VDName, &getModule());
+SetFunctionAttributes(Ve
@@ -689,7 +689,7 @@ if ( LLVM_COMPILER_IS_GCC_COMPATIBLE OR
CMAKE_CXX_COMPILER_ID MATCHES "XL" )
endif( LLVM_COMPILER_IS_GCC_COMPATIBLE OR CMAKE_CXX_COMPILER_ID MATCHES "XL" )
if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
- append("-Werror=unguarded-availability-new" CMAKE_C_FL
zmodem wrote:
A few notes from looking today.
Reduced main a bit further:
```
int main(int argc, const char** argv) {
volatile auto p = &FilteredBreakIteratorBuilder::createEmptyInstance;
icu::UnicodeString* St = new icu::UnicodeString("abacabadabacab", 15);
delete St;
printf("OKAY\n");
https://github.com/zmodem created
https://github.com/llvm/llvm-project/pull/133092
None
>From 7a874d12661de2fe93ac5eba8e68edf25053f462 Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Wed, 26 Mar 2025 15:24:44 +0100
Subject: [PATCH] [clang-cl] Accept the --warning-suppression-mappings= optio
zmodem wrote:
> but, that is still not a great reproducer for a reverted patch. Especially if
> the link issue is due to a missing support in linker. I would appreciate if
> you could maybe point to how exactly UnicodeString is used in failing
> scenario.
I'm sorry that we didn't catch this p
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/131188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wunnecessary-virtual-specifier %s
+
+struct Foo final {
+ Foo() = default;
+ virtual ~Foo() = default; // expected-warning {{virtual
method}}
+ virtual Foo& operator=(Foo& other) = default; // ex
zmodem wrote:
> What do you think about implementing the suggestion about checking if virtual
> methods actually get overridden or not?
Since we could only do it for classes with internal linkage, I think it's
probably not very valuable.
Warning about virtual functions that are not overriding
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -Wunnecessary-virtual-specifier %s
+
+struct Foo final {
+ Foo() = default;
+ virtual ~Foo() = default; // expected-warning {{virtual
method}}
+ virtual Foo& operator=(Foo& other) = default; // ex
https://github.com/zmodem commented:
Code and test lgtm, but I think we should consider enabling it by default.
https://github.com/llvm/llvm-project/pull/131188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/zmodem edited
https://github.com/llvm/llvm-project/pull/131188
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2706,6 +2706,9 @@ def warn_final_dtor_non_final_class : Warning<
InGroup;
def note_final_dtor_non_final_class_silence : Note<
"mark %0 as '%select{final|sealed}1' to silence this warning">;
+def warn_unnecessary_virtual_specifier : Warning<
+ "virtual method %0 is insi
zmodem wrote:
> It turns out another issue (https://crbug.com/402425841) also bisected to
> this PR. That one is a run-time problem, so it may be trickier to figure out,
> but I will look into it next.
The bugs seem related by both involving the ICU library, and if squinting a bit
it seems th
https://github.com/zmodem approved this pull request.
> We use existing support for the Microsoft extension type `__int128` which has
> been there for a long time. I feel like we should have appropriate coverage
> already
Sounds good to me.
lgtm with the i128 test that Fznamznon suggested, an
https://github.com/zmodem commented:
> Take the opportunity to tighten up the code slightly by ensuring that we do
> not access out-of-bounds characters when lexing the token.
That's a nice touch :-)
Do we already have tests somewhere checking that we can codegen this, or do we
need to add th
zmodem wrote:
I've put lld-link repro tarballs before and after the llvm change here:
https://issues.chromium.org/u/1/issues/402354446#comment8
https://github.com/llvm/llvm-project/pull/126240
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
zmodem wrote:
Yes, I'm prioritizing this today. I had hoped filteredbrk.obj was enough, but
I'm working on uploading full linker repros.
It turns out another issue (https://crbug.com/402425841) also bisected to this
PR. That one is a run-time problem, so it may be trickier to figure out, but I
https://github.com/zmodem approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/131036
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Hans Wennborg
Date: 2025-03-12T16:26:00+01:00
New Revision: e11ede5e90ee193dde179fe1a9ac9af718ede3db
URL:
https://github.com/llvm/llvm-project/commit/e11ede5e90ee193dde179fe1a9ac9af718ede3db
DIFF:
https://github.com/llvm/llvm-project/commit/e11ede5e90ee193dde179fe1a9ac9af718ede3db.diff
zmodem wrote:
We're hitting link errors after this change when building with sanitizer
coverage enabled:
```
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by obj/third_party/icu/icuuc_private/filteredbrk.obj:(.SCOVP$M)
>>> referenced by obj/third_party/ic
Author: Hans Wennborg
Date: 2025-03-12T12:31:37+01:00
New Revision: 76cf895717e9eba4d2a158d5bc3e48f2f7794181
URL:
https://github.com/llvm/llvm-project/commit/76cf895717e9eba4d2a158d5bc3e48f2f7794181
DIFF:
https://github.com/llvm/llvm-project/commit/76cf895717e9eba4d2a158d5bc3e48f2f7794181.diff
zmodem wrote:
This broke our builds. Here's a small repro:
```
$ cat /tmp/a.cc
#include
__m256i parens;
int f() {
return ((__v32qi)parens)[31];
}
$ build/bin/clang -c /tmp/a.cc
/tmp/a.cc:4:20: error: vector element index 31 is out of bounds
4 | return ((__v32qi)parens)[31];
|
Author: Hans Wennborg
Date: 2025-03-10T16:35:03+01:00
New Revision: c40f0fe4348bb9304b95bd317665bf1cb2bdcc85
URL:
https://github.com/llvm/llvm-project/commit/c40f0fe4348bb9304b95bd317665bf1cb2bdcc85
DIFF:
https://github.com/llvm/llvm-project/commit/c40f0fe4348bb9304b95bd317665bf1cb2bdcc85.diff
zmodem wrote:
This broke code using `modff` on 32-bit x86 Windows, where the runtime library
doesn't provide any `modff` symbol, rather it's implemented inline in `math.h`
(which calls `modf`):
```
>type \src\temp\a.c
#include
#include
float foo(float f) {
float i;
return modff(f, &i);
Author: Hans Wennborg
Date: 2025-03-10T14:02:04+01:00
New Revision: 28fa1fcf55b973e13018ac115fcbb357b4c0baad
URL:
https://github.com/llvm/llvm-project/commit/28fa1fcf55b973e13018ac115fcbb357b4c0baad
DIFF:
https://github.com/llvm/llvm-project/commit/28fa1fcf55b973e13018ac115fcbb357b4c0baad.diff
zmodem wrote:
We're seeing new -Wunguarded-availability warnings after this. A reduced
example:
```
$ cat /tmp/x.cc
template struct remove_cv { typedef T type; };
struct __attribute__((__availability__(android, introduced = 29)))
AAudioStreamWrapper { };
template struct Foo {
T *p;
};
te
zmodem wrote:
Ping?
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/129255
>From c1fe663ceacd31064b2758e43de1afc3f51d3f2c Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Fri, 28 Feb 2025 11:55:06 +0100
Subject: [PATCH 1/2] [Coroutines] Replace coro.outside.frame metadata with an
int
zmodem wrote:
(sorry, wrong button)
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem reopened
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
This is a follow-up to the discussion on the previous PR:
- I think that discussion ended with the conclusion that we need an explicit
mechanism for marking out-of-frame allocas.
- We agree it should not be metadata
- I think an intrinsic may be better than a flag directly on the
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/129255
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem approved this pull request.
lgtm
https://github.com/llvm/llvm-project/pull/129120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/129120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -855,6 +855,16 @@ void CodeGenFunction::EmitCoroutineBody(const
CoroutineBodyStmt &S) {
// Create parameter copies. We do it before creating a promise, since an
// evolution of coroutine TS may allow promise constructor to observe
// parameter copies.
+for (
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/127653
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/8] [Coroutines] Mark parameter allocas with
coro.outside.frame
zmodem wrote:
The discussion seems to be stalling. I'll try to summarize.
There seem to be two major questions:
1. Whether the front-end should explicitly mark some allocas as not belonging
in the coroutine frame, or whether we should enhance CoroSplit to infer it
automatically.
I think e
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/7] [Coroutines] Mark parameter allocas with
coro.outside.frame
@@ -6097,10 +6097,29 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
llvm::PrettyStackTraceString CrashInfo("Computing output path");
+
// Output to a user requested destination?
if (AtTopLevel && !isa(JA) && !isa(JA)) {
-if (Arg
@@ -14,3 +14,11 @@
//--- test.pcm
// CPP20WARNING-NOT: clang-cl: warning: argument unused during compilation:
'/std:c++20' [-Wunused-command-line-argument]
+
+// test whether the following outputs %Hello.bmi
+// RUN: %clang_cl /std:c++20 --precompile -x c++-module
-fmodule-o
@@ -6097,10 +6097,29 @@ const char *Driver::GetNamedOutputPath(Compilation &C,
const JobAction &JA,
}
llvm::PrettyStackTraceString CrashInfo("Computing output path");
+
// Output to a user requested destination?
if (AtTopLevel && !isa(JA) && !isa(JA)) {
-if (Arg
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -std=c++17 -Wno-all -Wunsafe-buffer-usage \
+// RUN:-verify %s
+
+// Previously we had a bug where we would diagnose *no* unsafe buffer warnings
+// if the warning was disabled by pragma and left disabled until end-of-TU.
+// This i
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -std=c++17 -Wno-all -Wunsafe-buffer-usage \
zmodem wrote:
nit: No need for the line break?
https://github.com/llvm/llvm-project/pull/128603
___
cfe-commits mailing list
cfe-commits@
https://github.com/zmodem approved this pull request.
https://github.com/llvm/llvm-project/pull/128603
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> Re: sroa/mem2reg, that's a valid concern with Hans's intrinsic approach.
Is it still a concern in the latest version, which makes mem2reg aware of the
intrinsic?
I don't have a good feel for whether putting a flag on `AllocaInst` or using an
intrinsic is less disruptive. Happy
zmodem wrote:
> > > My instinct reaction is, it may block some optimizations to optimize the
> > > alloca out.
> >
> >
> > The intrinsic gets dropped by CoroSplit, so after that it's not a problem.
> > Before that, I'm not sure much interesting optimization can happen to
> > allocas anyway?
https://github.com/zmodem updated
https://github.com/llvm/llvm-project/pull/127653
>From cde82a27139c39406a9afb5b471fa527e52e5bca Mon Sep 17 00:00:00 2001
From: Hans Wennborg
Date: Tue, 18 Feb 2025 15:27:37 +0100
Subject: [PATCH 1/6] [Coroutines] Mark parameter allocas with
coro.outside.frame
https://github.com/zmodem closed
https://github.com/llvm/llvm-project/pull/127843
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zmodem wrote:
> In the issue (#127499) you pointed out that this issue applies to the MSVC
> ABI where all parameters are destroyed in the callee. Is it reasonable to
> construct the analogous test case in that environment?
Yes, in fact the reproducer on that issue will trigger use-after-free
1 - 100 of 1672 matches
Mail list logo
