History log of /llvm-project-15.0.7/libcxx/src/new.cpp (Results 1 – 25 of 75)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2
# bbb0f2c7 11-Feb-2022 Arthur O'Dwyer <[email protected]>

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/inclu

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.

I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.

Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.

Differential Revision: https://reviews.llvm.org/D119561

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# eb8650a7 17-Nov-2021 Louis Dionne <[email protected]>

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1
# 4cd6ca10 20-Apr-2021 Louis Dionne <[email protected]>

[libc++] NFC: Normalize `#endif //` comment indentation


Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3
# 5601305f 01-Mar-2021 Louis Dionne <[email protected]>

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

Differential Revis

[libc++/abi] Replace uses of _NOEXCEPT in src/ by noexcept

We always build the libraries in a Standard mode that supports noexcept,
so there's no need to use the _NOEXCEPT macro.

Differential Revision: https://reviews.llvm.org/D97700

show more ...


Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2
# bc556e56 17-Dec-2020 Louis Dionne <[email protected]>

[libc++/abi] Re-remove unnecessary null pointer checks from operator delete

In 7cd67904f776, we removed the unnecessary nullptr checks from the libc++abi
definition of operator delete, but we forgot

[libc++/abi] Re-remove unnecessary null pointer checks from operator delete

In 7cd67904f776, we removed the unnecessary nullptr checks from the libc++abi
definition of operator delete, but we forgot to update the definition in
libc++ (damn code duplication!). Then, in d4a1e03c5fb5, I synced the
definitions across libc++ and libc++abi, but I did it the wrong way around.
I re-added the if() checks to libc++abi instead of removing them from libc++.

In ef74f0fdc339, we re-removed the if() check from operator delete, but
only in libc++abi. This patch corrects this mess and removes it
consistently in libc++ and libc++abi.

Differential Revision: https://reviews.llvm.org/D93473

show more ...


Revision tags: llvmorg-11.0.1-rc1
# 527a7fdf 24-Nov-2020 Bruce Mitchener <[email protected]>

[libc++] Replace several uses of 0 by nullptr

Differential Revision: https://reviews.llvm.org/D43159


# a78aaa1a 12-Nov-2020 Louis Dionne <[email protected]>

[libc++] Factor out common logic for calling aligned allocation

There were a couple of places where we needed to call the underlying
platform's aligned allocation/deallocation function. Instead of h

[libc++] Factor out common logic for calling aligned allocation

There were a couple of places where we needed to call the underlying
platform's aligned allocation/deallocation function. Instead of having
the same logic all over the place, extract the logic into a pair of
helper functions __libcpp_aligned_alloc and __libcpp_aligned_free.

The code in libcxxabi/src/fallback_malloc.cpp looks like it could be
simplified after this change -- I purposefully did not simplify it
further to keep this change as straightforward as possible, since it
is touching very important parts of the library.

Also, the changes in libcxx/src/new.cpp and libcxxabi/src/stdlib_new_delete.cpp
are basically the same -- I just kept both source files in sync.

The underlying reason for this refactoring is to make it easier to support
platforms that provide aligned allocation through C11's aligned_alloc
function instead of posix_memalign. After this change, we'll only have
to add support for that in a single place.

Differential Revision: https://reviews.llvm.org/D91379

show more ...


# d4a1e03c 11-Nov-2020 Louis Dionne <[email protected]>

[libc++] NFC: Synchronize libc++abi and libc++ new definitions

Some changes were made to the libc++abi new/delete definitions, but
they were not copied back to the libc++ definition. It sucks that w

[libc++] NFC: Synchronize libc++abi and libc++ new definitions

Some changes were made to the libc++abi new/delete definitions, but
they were not copied back to the libc++ definition. It sucks that we
have this duplication, but for now at least let's keep them in sync.

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1
# a4bd340b 17-Apr-2019 Louis Dionne <[email protected]>

[libc++][CMake] Remove unnecessary conditional for defining new handlers

It turns out that whether the new handlers should be provided is orthogonal
to whether new/delete are provided in libc++ or l

[libc++][CMake] Remove unnecessary conditional for defining new handlers

It turns out that whether the new handlers should be provided is orthogonal
to whether new/delete are provided in libc++ or libc++abi. The reason why
I initially added this conditional is because of an incorrect understanding
of the path we're taking when building on Apple platforms. In fact, we
always build libc++ on top of libc++abi on Apple platforms, so we take
the branch for `LIBCXX_BUILDING_LIBCXXABI` there.

llvm-svn: 358616

show more ...


# 3084db3b 16-Apr-2019 Louis Dionne <[email protected]>

[libc++] Remove old workaround for buildit

Summary:
I'm not sure what the problem was at the time, however I don't think
this is necessary since buildit doesn't exist anymore.

Instead of the workar

[libc++] Remove old workaround for buildit

Summary:
I'm not sure what the problem was at the time, however I don't think
this is necessary since buildit doesn't exist anymore.

Instead of the workaround, the correct thing to do is to leave out
the get_new_handler/set_new_handler definitions from libc++ when
we're getting them from libc++abi.

Reviewers: EricWF

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D60717

llvm-svn: 358518

show more ...


# f0d7d87a 21-Mar-2019 Louis Dionne <[email protected]>

[NFC][libc++] Reindent #ifdefs

I don't understand why we don't always do that. We do it for normal `if`s
in the code, but not for preprocessor `if`s? It's a lot more readable when
indented properly.

[NFC][libc++] Reindent #ifdefs

I don't understand why we don't always do that. We do it for normal `if`s
in the code, but not for preprocessor `if`s? It's a lot more readable when
indented properly.

llvm-svn: 356693

show more ...


Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4
# e69290dc 05-Mar-2019 Eric Fiselier <[email protected]>

Make VCRuntime ABI configuration a first-class option.

Summary:
On Windows we currently provide two separate ABI configurations. One which defers to `vcruntime` to provide the C++ runtime and anothe

Make VCRuntime ABI configuration a first-class option.

Summary:
On Windows we currently provide two separate ABI configurations. One which defers to `vcruntime` to provide the C++ runtime and another which doesn't.
Using `vcruntime` allows interoperability which programs compiled against the MSVC STL, and should be preferred whenever possible.

When deferring to `vcruntime` much of the ABI we provide changes. Including the layout of `<stdexcept>` types, their vtables, and how the linkage of their members.

This patch introduces the `_LIBCPP_ABI_VCRUNTIME` macro to denote this configuration. It also cleans up the existing configuration for using `vcruntime`.

This cleanup lays the groundwork for fixing a number of ABI and interoperability bugs in `<stdexcept>`.


Reviewers: thomasanderson, ldionne, smeenai

Reviewed By: smeenai

Subscribers: jdoerfert, libcxx-commits, #libc

Differential Revision: https://reviews.llvm.org/D58942

llvm-svn: 355366

show more ...


Revision tags: llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2
# 3663f26f 30-Jan-2019 Thomas Anderson <[email protected]>

[libc++] Explicitly initialize std::nothrow

When building on Windows without libc++abi, this change fixes a build error of the form:

src/new.cpp(38,17): error: chosen constructor is explicit i

[libc++] Explicitly initialize std::nothrow

When building on Windows without libc++abi, this change fixes a build error of the form:

src/new.cpp(38,17): error: chosen constructor is explicit in copy-initialization
const nothrow_t nothrow = {};
include/vcruntime_new.h(53,22): note: explicit constructor declared here
explicit nothrow_t() = default;

Differential Revision: https://reviews.llvm.org/D57351

llvm-svn: 352648

show more ...


Revision tags: llvmorg-8.0.0-rc1
# 57b08b09 19-Jan-2019 Chandler Carruth <[email protected]>

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648

show more ...


Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1
# 42f9868c 11-Oct-2018 Eric Fiselier <[email protected]>

Distinguish between library and language support for aligned allocation.

There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support al

Distinguish between library and language support for aligned allocation.

There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support aligned allocation.
2. The compiler has actually turned the language feature on.

There are times where libc++ needs to distinguish between the two.

This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.

Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.

llvm-svn: 344207

show more ...


# 7cd67904 01-Oct-2018 Fangrui Song <[email protected]>

Remove redundant null pointer check in operator delete

Summary:
C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function

If ptr is a null pointer, no action

Remove redundant null pointer check in operator delete

Summary:
C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function

If ptr is a null pointer, no action shall occur.

_aligned_free on MSDN:

If memblock is a NULL pointer, this function simply performs no actions.

Reviewers: EricWF, mclow.lists, khng300, hotpxl

Reviewed By: mclow.lists, khng300, hotpxl

Subscribers: lichray, llvm-commits, hotpxl, khng300, christof, ldionne, cfe-commits, libcxx-commits

Differential Revision: https://reviews.llvm.org/D52401

llvm-svn: 343503

show more ...


# 3c3e1c62 25-Sep-2018 Louis Dionne <[email protected]>

Revert r342936 "Remove redundant null pointer check in operator delete"

A review for the change was opened in https://reviews.llvm.org/D52401
but the change was committed before being approved by an

Revert r342936 "Remove redundant null pointer check in operator delete"

A review for the change was opened in https://reviews.llvm.org/D52401
but the change was committed before being approved by any of the code
owners for libc++.

llvm-svn: 342938

show more ...


# 6da5366e 25-Sep-2018 Fangrui Song <[email protected]>

Remove redundant null pointer check in operator delete

C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function

If ptr is a null pointer, no action shall occ

Remove redundant null pointer check in operator delete

C89 4.10.3.2 The free function
C99 7.20.3.2 The free function
C11 7.22.3.3 The free function

If ptr is a null pointer, no action shall occur.

_aligned_free on MSDN:

If memblock is a NULL pointer, this function simply performs no actions.

Reviewers: EricWF, mclow.lists

Subscribers: christof, ldionne, cfe-commits, libcxx-commits

Differential Revision: https://reviews.llvm.org/D52401

llvm-svn: 342936

show more ...


Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1
# c8e84ff2 01-Aug-2018 Louis Dionne <[email protected]>

[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY

Summary: As suggested by Marshall in https://reviews.llvm.org/D49914

Reviewers: mclow.lists, EricWF

[libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since _LIBCPP_BUILDING_LIBRARY

Summary: As suggested by Marshall in https://reviews.llvm.org/D49914

Reviewers: mclow.lists, EricWF

Subscribers: christof, dexonsmith, cfe-commits

Differential Revision: https://reviews.llvm.org/D50008

llvm-svn: 338475

show more ...


Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1
# 492d7134 09-Oct-2017 Shoaib Meenai <[email protected]>

[libc++] Support Microsoft ABI without vcruntime headers

The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by

[libc++] Support Microsoft ABI without vcruntime headers

The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by deferring to the vcruntime headers and silencing its own definitions,
but for clients which don't want to depend on vcruntime headers, it's
desirable to support the opposite, i.e. have libc++ provide its own
definitions.

Certain operator new/delete replacement scenarios are not currently
supported in this mode, which requires some tests to be marked XFAIL.
The added documentation has more details.

Differential Revision: https://reviews.llvm.org/D38522

llvm-svn: 315234

show more ...


# fbfaec70 19-Sep-2017 Weiming Zhao <[email protected]>

[libc++] Replace __sync_* functions with __libcpp_atomic_* functions

Summary:
This patch replaces __sync_* with __libcpp_atomic_* and adds a wrapper
function for __atomic_exchange to support _LIBCPP

[libc++] Replace __sync_* functions with __libcpp_atomic_* functions

Summary:
This patch replaces __sync_* with __libcpp_atomic_* and adds a wrapper
function for __atomic_exchange to support _LIBCPP_HAS_NO_THREADS.

Reviewers: EricWF, jroelofs, mclow.lists, compnerd

Reviewed By: EricWF, compnerd

Subscribers: compnerd, efriedma, cfe-commits, joerg, llvm-commits

Differential Revision: https://reviews.llvm.org/D35235

llvm-svn: 313694

show more ...


Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3
# 1ec02625 31-May-2017 Eric Fiselier <[email protected]>

Fix Libc++ build with MinGW64

Summary: This patch corrects the build errors I encountered when building on MinGW64.

Reviewers: mati865, rnk, compnerd, smeenai, bcraig

Reviewed By: mati865, smeenai

Fix Libc++ build with MinGW64

Summary: This patch corrects the build errors I encountered when building on MinGW64.

Reviewers: mati865, rnk, compnerd, smeenai, bcraig

Reviewed By: mati865, smeenai

Subscribers: martell, chapuni, cfe-commits

Differential Revision: https://reviews.llvm.org/D33082

llvm-svn: 304360

show more ...


Revision tags: llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4
# 3499263c 02-Mar-2017 Eric Fiselier <[email protected]>

[libc++] Add option to disable new/delete overloads when libc++abi provides them.

Summary:
Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is

[libc++] Add option to disable new/delete overloads when libc++abi provides them.

Summary:
Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them.

This patch adds the CMake option `-DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS` which defaults no `ON` unless `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS=ON` is specified.



Reviewers: mclow.lists, mehdi_amini, dexonsmith, danalbert, smeenai, mgorny, rmaprath

Reviewed By: mehdi_amini

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D30516

llvm-svn: 296802

show more ...


Revision tags: llvmorg-4.0.0-rc3
# 637160c5 10-Feb-2017 Eric Fiselier <[email protected]>

Attempt to fix Apple buildit bots

llvm-svn: 294731


# d22c9dc4 10-Feb-2017 Eric Fiselier <[email protected]>

Recommit "Split exception.cpp and new.cpp implementation into different files for different runtimes."

This recommits r294707 with additional fixes. The main difference is
libc++ now correctly build

Recommit "Split exception.cpp and new.cpp implementation into different files for different runtimes."

This recommits r294707 with additional fixes. The main difference is
libc++ now correctly builds without any ABI library.

exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.

This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.

This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.

llvm-svn: 294730

show more ...


123