github-actions[bot] wrote:
@Aethezz Congratulations on having your first Pull Request (PR) merged into the
LLVM Project!
Your changes will be combined with recent changes from other authors, then
tested by our [build bots](https://lab.llvm.org/buildbot/). If there is a
problem with a build,
https://github.com/steakhal closed
https://github.com/llvm/llvm-project/pull/150161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/steakhal approved this pull request.
https://github.com/llvm/llvm-project/pull/150161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Aethezz updated
https://github.com/llvm/llvm-project/pull/150161
>From a018c87c6356326cb04bd0a98ff5842e07403f9c Mon Sep 17 00:00:00 2001
From: Aethezz <64500703+aeth...@users.noreply.github.com>
Date: Tue, 22 Jul 2025 23:19:11 -0400
Subject: [PATCH 1/4] fix false positive, war
@@ -111,32 +111,13 @@ bool PlacementNewChecker::checkPlaceCapacityIsSufficient(
if (!SizeOfPlaceCI)
return true;
- if ((SizeOfPlaceCI->getValue() < SizeOfTargetCI->getValue()) ||
- (IsArrayTypeAllocated &&
- SizeOfPlaceCI->getValue() >= SizeOfTargetCI->getVal
steakhal wrote:
This is really scary. Thanks for the really deep dive in the subject.
Frankly, any of the aformentioned ways are fine by me. Just removing (what is
the current state of the PR) is probably the easiest. If you wish, we can
overcomplicate this, but frankly, I don't want to support
puetzk wrote:
Just for sake of linkdumping,
https://developercommunity.visualstudio.com/t/Non-allocating-placement-array-new-somet/10777485?sort=active
shows another (later) regression when the type in question come from a
template parameter.
https://github.com/llvm/llvm-project/pull/150161
_
puetzk wrote:
Hmm. The test case presented in that
https://stackoverflow.com/questions/15254/can-placement-new-for-arrays-be-used-in-a-portable-way/75418614#75418614
link *does* show MSVC misbehaving as late as VS 2019 16.5 (for some reason
MSVC 16.6 is missing on godbolt). https://godbolt.org
https://github.com/Aethezz updated
https://github.com/llvm/llvm-project/pull/150161
>From a018c87c6356326cb04bd0a98ff5842e07403f9c Mon Sep 17 00:00:00 2001
From: Aethezz <64500703+aeth...@users.noreply.github.com>
Date: Tue, 22 Jul 2025 23:19:11 -0400
Subject: [PATCH 1/3] fix false positive, war
@@ -0,0 +1,24 @@
+// RUN: %clang -fsyntax-only -Xclang -analyze -Xclang
-analyzer-checker=cplusplus.PlacementNew -Xclang -verify -std=c++17 %s
+
+#include
+
+void test_exact_size() {
+void *buf = ::operator new(sizeof(int)*2);
+int *placement_int = new (buf) int[2]; // n
@@ -111,32 +111,14 @@ bool PlacementNewChecker::checkPlaceCapacityIsSufficient(
if (!SizeOfPlaceCI)
return true;
- if ((SizeOfPlaceCI->getValue() < SizeOfTargetCI->getValue()) ||
- (IsArrayTypeAllocated &&
- SizeOfPlaceCI->getValue() >= SizeOfTargetCI->getVal
https://github.com/steakhal edited
https://github.com/llvm/llvm-project/pull/150161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,24 @@
+// RUN: %clang -fsyntax-only -Xclang -analyze -Xclang
-analyzer-checker=cplusplus.PlacementNew -Xclang -verify -std=c++17 %s
steakhal wrote:
```suggestion
// RUN: %clang_analyze_cc1 -analyzer-checker=core,cplusplus.PlacementNew
-verify -std=c+
https://github.com/steakhal requested changes to this pull request.
> @steakhal What do you think, which would be the better: merging this PR or
> preserving the counter-intuitive bug reports that warn about potential
> unusual behavior of array placement new?
The PR looks good. I don't think
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/150161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,24 @@
+// RUN: %clang -fsyntax-only -Xclang -analyze -Xclang
-analyzer-checker=cplusplus.PlacementNew -Xclang -verify -std=c++17 %s
+
+#include
+
+void test_exact_size() {
+void *buf = ::operator new(sizeof(int)*2);
+int *placement_int = new (buf) int[2]; // n
@@ -0,0 +1,24 @@
+// RUN: %clang -fsyntax-only -Xclang -analyze -Xclang
-analyzer-checker=cplusplus.PlacementNew -Xclang -verify -std=c++17 %s
+
+#include
NagyDonat wrote:
These tests do not include real system headers (if I understand correctly, this
is becau
https://github.com/NagyDonat commented:
I added some technical remarks in inline comments. If those are handled, I'm
leaning towards merging this PR, because it I agree that these warnings (where
the array would fit into the buffer where it's initialized, but the overhead of
the array new can
https://github.com/NagyDonat edited
https://github.com/llvm/llvm-project/pull/150161
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -179,8 +179,8 @@ void f2() {
// maybe ok but we need to warn.
NagyDonat wrote:
Similarly to the previous comment, explain that this testcase is a situation
that _could_ be problematic, but the checker doesn't report it.
https://github.com/llvm/llvm-proj
@@ -168,8 +168,8 @@ void f1() {
// bad (not enough space).
NagyDonat wrote:
If you change the behavior of this checker in this situation, then please
update this comment and explain that the code of the test would be problematic
on systems where placement
Aethezz wrote:
Hello, this is my first contribution and I am unsure of the process. I have
tried fixing the formatting issues and failing test case from other unit tests.
After viewing your discussions, is this still a valid issue?
https://github.com/llvm/llvm-project/pull/150161
https://github.com/Aethezz updated
https://github.com/llvm/llvm-project/pull/150161
>From a018c87c6356326cb04bd0a98ff5842e07403f9c Mon Sep 17 00:00:00 2001
From: Aethezz <64500703+aeth...@users.noreply.github.com>
Date: Tue, 22 Jul 2025 23:19:11 -0400
Subject: [PATCH 1/2] fix false positive, war
steakhal wrote:
> > I never understood the reasons of having metadata for placement-new.
>
> I don't think that there is any real reason for it, but I guess that some
> compilers reused code from the code of non-placement new.
>
> > Certainly on linux it was not the case, but I'm skeptical if
NagyDonat wrote:
> I never understood the reasons of having metadata for placement-new.
I don't think that there is any real reason for it, but I guess that some
compilers reused code from the code of non-placement new.
> Certainly on linux it was not the case, but I'm skeptical if it was on a
steakhal wrote:
> The code that you're removing is not an accidental bug, but an intentional
> (although perhaps overzealous) feature that tries to warn about the fact that
> placement new for an array type may allocate an unspecified amount of
> overhead (extra memory) for internal needs.
>
https://github.com/NagyDonat commented:
The code that you're removing is not an accidental bug, but an intentional
(although perhaps overzealous) feature that tries to warn about the fact that
placement new for an array type may allocate an unspecified amount of overhead
(extra memory) for int
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff HEAD~1 HEAD --extensions cpp --
clang/test/SemaCXX/placement-new-bounds.cpp
clang/li
28 matches
Mail list logo
