nico wrote:
This causes #95451.
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
glandium wrote:
Yes
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
wangpc-pp wrote:
> Filed https://gitlab.kitware.com/cmake/cmake/-/issues/26031
So this is a cmake bug, not clang's, right?
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
glandium wrote:
Filed https://gitlab.kitware.com/cmake/cmake/-/issues/26031
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
glandium wrote:
There is something wrong going on with cmake:
STR:
- Download
[testcase.zip](https://github.com/user-attachments/files/15597940/testcase.zip)
- Unzip it (it contains ClangRepl.cpp.obj and exports.def.objs)
- Run `cmake -E __create_def exports.def exports.def.objs
glandium wrote:
> Mainly about the commands of cmake building.
However you build clang on windows using clang, with the addition of
-DLLVM_BUILD_INSTRUMENTED=IR -DLLVM_BUILD_RUNTIME=No
> Does this failure bind to a buildbot?
I have no idea, but probably not, otherwise you'd have heard from
vgvassilev wrote:
It seems we have troubles with exporting the right symbols on windows. I am
cc-ing @compnerd and @fsfod for more expertise.
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
wangpc-pp wrote:
> What kind of detail are you looking for?
Mainly about the commands of cmake building. Does this failure bind to a
buildbot?
And can @AaronBallman @vitalybuka @vgvassilev help me to figure this out?
https://github.com/llvm/llvm-project/pull/90373
glandium wrote:
What kind of detail are you looking for?
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
wangpc-pp wrote:
> This broke building clang on Windows with PGO:
>
> ```
> FAILED: bin/clang-repl.exe lib/clang-repl.lib
> cmd.exe /C "cmd.exe /C "D:\task_171745452431588\fetches\cmake\bin\cmake.exe
> -E __create_def
>
glandium wrote:
This broke building clang on Windows with PGO:
```
FAILED: bin/clang-repl.exe lib/clang-repl.lib
cmd.exe /C "cmd.exe /C "D:\task_171745452431588\fetches\cmake\bin\cmake.exe -E
__create_def
wangpc-pp wrote:
Thanks @vitalybuka for fixing the remain issues.
It has been about 2 days since this PR was merged and there is no other issue,
I think we finally make sized deallocation default this time! Cheers!
https://github.com/llvm/llvm-project/pull/90373
wangpc-pp wrote:
Thanks @vitalybuka! After some investigations, I think this PR just uncovered
the existed ASAN problem.
```cpp
#if !defined(__cpp_sized_deallocation) || __cpp_sized_deallocation < 201309L
# define _LIBCPP_HAS_NO_LANGUAGE_SIZED_DEALLOCATION
#endif
#if
vitalybuka wrote:
Internally ::allocate uses sided new:
```
void*
allocate(size_t __bytes, size_t __alignment = _S_max_align)
__attribute__((__returns_nonnull__,__alloc_size__(2),__alloc_align__(3)))
{ return ::operator new(__bytes, do_allocate(__bytes, __alignment)); }
```
vitalybuka wrote:
> > > Based on my rough understanding, this is expected?
> >
> >
> > What do you mean?
> > Isn't this test needs to be updated or disabled?
>
> I think this ASAN failure is not caused by this PR because these memorys are
> allocated/deallocated by
100% sure by this PR
wangpc-pp wrote:
> > Based on my rough understanding, this is expected?
>
> What do you mean?
>
> Isn't this test needs to be updated or disabled?
I think this ASAN failure is not caused by this PR because these memorys are
allocated/deallocated by `memory_resource` directly, **there is
vitalybuka wrote:
> Based on my rough understanding, this is expected?
What do you mean?
Isn't this test needs to be updated or disabled?
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
wangpc-pp wrote:
> This one is broken https://lab.llvm.org/buildbot/#/builders/168/builds/20461
The broken case is:
```cpp
void test_allocate_deallocate() {
std::pmr::memory_resource& r1 = *std::pmr::new_delete_resource();
globalMemCounter.reset();
void* ret = r1.allocate(50);
vitalybuka wrote:
This one is broken https://lab.llvm.org/buildbot/#/builders/168/builds/20461
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/wangpc-pp closed
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/wangpc-pp updated
https://github.com/llvm/llvm-project/pull/90373
>From a18f57e23c0d4fd23647eb2ef610352e402b45f6 Mon Sep 17 00:00:00 2001
From: Pengcheng Wang
Date: Fri, 26 Apr 2024 16:59:12 +0800
Subject: [PATCH] [clang] Enable sized deallocation by default in C++14 onwards
https://github.com/ldionne approved this pull request.
Let's try this again. Thanks for your perseverance, this is obviously not easy
to land but it's important to get it done. Let's hope everything has been
addressed this time around.
https://github.com/llvm/llvm-project/pull/90373
wangpc-pp wrote:
Please review this PR as all noticable issues have been fixed I think.
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/wangpc-pp updated
https://github.com/llvm/llvm-project/pull/90373
>From fd015302585fc8149811868636cb0da5c422cf7a Mon Sep 17 00:00:00 2001
From: Pengcheng Wang
Date: Fri, 26 Apr 2024 16:59:12 +0800
Subject: [PATCH] [clang] Enable sized deallocation by default in C++14 onwards
vitalybuka wrote:
> Thanks a lot, that was quick! There is another AddressSanitizer issue that
> may possibly be fixed by #90292. cc @vitalybuka
Yes, please wait for #90292.
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing
wangpc-pp wrote:
> > > @dyung Can you help me to comfirm whether the Windows builder is passing
> > > now? I don't have such environment. Thanks in advance!
> >
> >
> > Sure, I'll try it on our internal builder and see if it passes and let you
> > know the result.
>
> I can confirm that
dyung wrote:
> > @dyung Can you help me to comfirm whether the Windows builder is passing
> > now? I don't have such environment. Thanks in advance!
>
> Sure, I'll try it on our internal builder and see if it passes and let you
> know the result.
I can confirm that this change builds
dyung wrote:
> @dyung Can you help me to comfirm whether the Windows builder is passing now?
> I don't have such environment. Thanks in advance!
Sure, I'll try it on our internal builder and see if it passes and let you know
the result.
https://github.com/llvm/llvm-project/pull/90373
wangpc-pp wrote:
@dyung Can you help me to comfirm whether the Windows builder is passing now? I
don't have such environment. Thanks in advance!
https://github.com/llvm/llvm-project/pull/90373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
llvmbot wrote:
@llvm/pr-subscribers-clang-tidy
Author: Pengcheng Wang (wangpc-pp)
Changes
Since C++14 has been released for about nine years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
This is another try of
llvmbot wrote:
@llvm/pr-subscribers-coroutines
@llvm/pr-subscribers-libcxx
Author: Pengcheng Wang (wangpc-pp)
Changes
Since C++14 has been released for about nine years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
https://github.com/wangpc-pp created
https://github.com/llvm/llvm-project/pull/90373
Since C++14 has been released for about nine years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
This is another try of
32 matches
Mail list logo
