maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/operator-new.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

30 lines
991 B
C++
Raw Normal View History

Reverting r216675. This breaks some bots. Before this can be committed again, I have to explore runtime ABI requirements with libc++abi. llvm-svn: 216677
2014-08-29 01:24:14 +08:00
// RUN: %clang_cc1 -triple i686-pc-linux-gnu -emit-llvm -o %t-1.ll %s
[clang] Annotating C++'s `operator new` with more attributes Summary: Right now we annotate C++'s `operator new` with `noalias` attribute, which very much is healthy for optimizations. However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]], there are more promises on global `operator new`, namely: * non-`std::nothrow_t` `operator new` *never* returns `nullptr` * If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned * ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that. Supplying this information may not cause immediate landslide effects on any specific benchmarks, but it for sure will be healthy for optimizer in the sense that the IR will better reflect the guarantees provided in the source code. The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias` attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes? The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`. But while it is okay to add `noalias` metadata in backend, we really should be adding at least the alignment metadata to the AST, since that allows us to perform sema checks on it. Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith Reviewed By: rsmith Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
// RUN: FileCheck --check-prefix=ALL -check-prefix SANE --input-file=%t-1.ll %s
Reverting r216675. This breaks some bots. Before this can be committed again, I have to explore runtime ABI requirements with libc++abi. llvm-svn: 216677
2014-08-29 01:24:14 +08:00
// RUN: %clang_cc1 -triple i686-pc-linux-gnu -emit-llvm -fno-assume-sane-operator-new -o %t-2.ll %s
[clang] Annotating C++'s `operator new` with more attributes Summary: Right now we annotate C++'s `operator new` with `noalias` attribute, which very much is healthy for optimizations. However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]], there are more promises on global `operator new`, namely: * non-`std::nothrow_t` `operator new` *never* returns `nullptr` * If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned * ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that. Supplying this information may not cause immediate landslide effects on any specific benchmarks, but it for sure will be healthy for optimizer in the sense that the IR will better reflect the guarantees provided in the source code. The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias` attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes? The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`. But while it is okay to add `noalias` metadata in backend, we really should be adding at least the alignment metadata to the AST, since that allows us to perform sema checks on it. Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith Reviewed By: rsmith Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
// RUN: FileCheck --check-prefix=ALL -check-prefix SANENOT --input-file=%t-2.ll %s
implement PR5654: add -fassume-sane-operator-new, which is enabled by default, and adds the malloc attribute to the global function new() and to the overloaded new operators. feel free to chage the name to this lengthy argument llvm-svn: 91543
2009-12-17 00:59:22 +08:00
class teste {
int A;
Turn access control on by default in -cc1. Remove -faccess-control from -cc1; add -fno-access-control. Make the driver pass -fno-access-control by default. Update a bunch of tests to be correct under access control. llvm-svn: 100880
2010-04-10 03:03:51 +08:00
public:
implement PR5654: add -fassume-sane-operator-new, which is enabled by default, and adds the malloc attribute to the global function new() and to the overloaded new operators. feel free to chage the name to this lengthy argument llvm-svn: 91543
2009-12-17 00:59:22 +08:00
teste() : A(2) {}
};
void f1() {
[clang] Annotating C++'s `operator new` with more attributes Summary: Right now we annotate C++'s `operator new` with `noalias` attribute, which very much is healthy for optimizations. However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]], there are more promises on global `operator new`, namely: * non-`std::nothrow_t` `operator new` *never* returns `nullptr` * If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned * ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that. Supplying this information may not cause immediate landslide effects on any specific benchmarks, but it for sure will be healthy for optimizer in the sense that the IR will better reflect the guarantees provided in the source code. The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias` attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes? The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`. But while it is okay to add `noalias` metadata in backend, we really should be adding at least the alignment metadata to the AST, since that allows us to perform sema checks on it. Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith Reviewed By: rsmith Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
// ALL: declare nonnull i8* @_Znwj(
implement PR5654: add -fassume-sane-operator-new, which is enabled by default, and adds the malloc attribute to the global function new() and to the overloaded new operators. feel free to chage the name to this lengthy argument llvm-svn: 91543
2009-12-17 00:59:22 +08:00
new teste();
}
implement rdar://5739832 - operator new should check for overflow in multiply, causing clang to compile this code into something that correctly throws a length error, fixing a potential integer overflow security attack: void *test(long N) { return new int[N]; } int main() { test(1L << 62); } We do this even when exceptions are disabled, because it is better for the code to abort than for the attack to succeed. This is heavily based on a patch that Fariborz wrote. llvm-svn: 108915
2010-07-21 04:19:24 +08:00
// rdar://5739832 - operator new should check for overflow in multiply.
void *f2(long N) {
return new int[N];
[clang] Annotating C++'s `operator new` with more attributes Summary: Right now we annotate C++'s `operator new` with `noalias` attribute, which very much is healthy for optimizations. However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]], there are more promises on global `operator new`, namely: * non-`std::nothrow_t` `operator new` *never* returns `nullptr` * If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned * ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that. Supplying this information may not cause immediate landslide effects on any specific benchmarks, but it for sure will be healthy for optimizer in the sense that the IR will better reflect the guarantees provided in the source code. The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias` attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes? The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`. But while it is okay to add `noalias` metadata in backend, we really should be adding at least the alignment metadata to the AST, since that allows us to perform sema checks on it. Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith Reviewed By: rsmith Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
// ALL: [[UWO:%.*]] = call {{.*}} @llvm.umul.with.overflow
// ALL-NEXT: [[OVER:%.*]] = extractvalue {{.*}} [[UWO]], 1
// ALL-NEXT: [[SUM:%.*]] = extractvalue {{.*}} [[UWO]], 0
// ALL-NEXT: [[RESULT:%.*]] = select i1 [[OVER]], i32 -1, i32 [[SUM]]
// SANE-NEXT: call noalias nonnull i8* @_Znaj(i32 [[RESULT]])
// SANENOT-NEXT: call nonnull i8* @_Znaj(i32 [[RESULT]])
implement rdar://5739832 - operator new should check for overflow in multiply, causing clang to compile this code into something that correctly throws a length error, fixing a potential integer overflow security attack: void *test(long N) { return new int[N]; } int main() { test(1L << 62); } We do this even when exceptions are disabled, because it is better for the code to abort than for the attack to succeed. This is heavily based on a patch that Fariborz wrote. llvm-svn: 108915
2010-07-21 04:19:24 +08:00
}
Replace Sema-level implementation of -fassume-sane-operator-new with a CodeGen-level implementation. Instead of adding an attribute to clang's FunctionDecl, add the IR attribute directly. This means a module built with this flag is now compatible with code built without it and vice versa. This change also results in the 'noalias' attribute no longer being added to calls to operator new in the IR; it's now only added to the declaration. It also fixes a bug where we failed to add the attribute to the 'nothrow' versions (because we didn't implicitly declare them, there was no good time to inject a fake attribute). llvm-svn: 265728
2016-04-08 05:46:12 +08:00
[clang] Annotating C++'s `operator new` with more attributes Summary: Right now we annotate C++'s `operator new` with `noalias` attribute, which very much is healthy for optimizations. However as per [[ http://eel.is/c++draft/basic.stc.dynamic.allocation | `[basic.stc.dynamic.allocation]` ]], there are more promises on global `operator new`, namely: * non-`std::nothrow_t` `operator new` *never* returns `nullptr` * If `std::align_val_t align` parameter is taken, the pointer will also be `align`-aligned * ~~global `operator new`-returned pointer is `__STDCPP_DEFAULT_NEW_ALIGNMENT__`-aligned ~~ It's more caveated than that. Supplying this information may not cause immediate landslide effects on any specific benchmarks, but it for sure will be healthy for optimizer in the sense that the IR will better reflect the guarantees provided in the source code. The caveat is `-fno-assume-sane-operator-new`, which currently prevents emitting `noalias` attribute, and is automatically passed by Sanitizers ([[ https://bugs.llvm.org/show_bug.cgi?id=16386 | PR16386 ]]) - should it also cover these attributes? The problem is that the flag is back-end-specific, as seen in `test/Modules/explicit-build-flags.cpp`. But while it is okay to add `noalias` metadata in backend, we really should be adding at least the alignment metadata to the AST, since that allows us to perform sema checks on it. Reviewers: erichkeane, rjmccall, jdoerfert, eugenis, rsmith Reviewed By: rsmith Subscribers: xbolva00, jrtc27, atanasyan, nlopes, cfe-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D73380
2020-02-26 06:37:17 +08:00
// ALL: declare nonnull i8* @_Znaj(