| #
f05779e2 |
| 21-Jul-2015 |
David Blaikie <[email protected]> |
Pass an iterator range to EmitCallArgs
llvm-svn: 242824
|
|
Revision tags: llvmorg-3.7.0-rc1 |
|
| #
4ba525b7 |
| 14-Jul-2015 |
David Blaikie <[email protected]> |
Rely on default zero-arg value for IRBuilder::CreateCall calls to zero-arg functions
Patch by servuswiegehtz at yahoo.de
llvm-svn: 242168
|
| #
03ce2a16 |
| 10-Jul-2015 |
Ulrich Weigand <[email protected]> |
Respect alignment of nested bitfields
tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test:
struct XBitfield { unsigned b1 : 10; unsigned b2 : 12; unsigned b3 : 10; }; struct YB
Respect alignment of nested bitfields
tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test:
struct XBitfield { unsigned b1 : 10; unsigned b2 : 12; unsigned b3 : 10; }; struct YBitfield { char x; struct XBitfield y; } __attribute((packed)); struct YBitfield gbitfield;
unsigned test7() { // CHECK: @test7 // CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4 return gbitfield.y.b2; }
The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single i32 is of course possible, but that still doesn't make it 4-byte aligned as it remains packed at offset 1 in the surrounding gbitfield object.
This alignment was changed by commit r169489, which also introduced changes to bitfield access code in CGExpr.cpp. Code before that change used to take into account *both* the alignment of the field to be accessed within the current struct, *and* the alignment of that outer struct itself; this logic was removed by the above commit.
Neglecting to consider both values can cause incorrect code to be generated (I've seen an unaligned access crash on SystemZ due to this bug).
In order to always use the best known alignment value, this patch removes the CGBitFieldInfo::StorageAlignment member and replaces it with a StorageOffset member specifying the offset from the start of the surrounding struct to the bitfield's underlying storage. This offset can then be combined with the best-known alignment for a bitfield access lvalue to determine the alignment to use when accessing the bitfield's storage.
Differential Revision: http://reviews.llvm.org/D11034
llvm-svn: 241916
show more ...
|
| #
85365cd7 |
| 02-Jul-2015 |
Akira Hatanaka <[email protected]> |
Attach attribute "trap-func-name" to call sites of llvm.trap and llvm.debugtrap.
This is needed to use clang's command line option "-ftrap-function" for LTO and enable changing the trap function nam
Attach attribute "trap-func-name" to call sites of llvm.trap and llvm.debugtrap.
This is needed to use clang's command line option "-ftrap-function" for LTO and enable changing the trap function name on a per-call-site basis.
rdar://problem/21225723
Differential Revision: http://reviews.llvm.org/D10831
llvm-svn: 241306
show more ...
|
|
Revision tags: llvmorg-3.6.2, llvmorg-3.6.2-rc1 |
|
| #
ab9db510 |
| 22-Jun-2015 |
Alexander Kornienko <[email protected]> |
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").
llvm-svn: 240353
|
| #
3d9d929e |
| 22-Jun-2015 |
Alexander Kornienko <[email protected]> |
Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comme
Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
show more ...
|
| #
6708c4a1 |
| 19-Jun-2015 |
Peter Collingbourne <[email protected]> |
Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.
This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting.
Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.
This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library.
The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc.
Differential Revision: http://reviews.llvm.org/D10268
llvm-svn: 240109
show more ...
|
| #
9881b78b |
| 18-Jun-2015 |
Peter Collingbourne <[email protected]> |
Introduce -fsanitize-trap= flag.
This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error ha
Introduce -fsanitize-trap= flag.
This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined.
This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight).
Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined.
Differential Revision: http://reviews.llvm.org/D10464
llvm-svn: 240105
show more ...
|
| #
43f9bb73 |
| 18-May-2015 |
David Blaikie <[email protected]> |
API update for streamlining of IRBuilder::CreateCall to just use ArrayRef/initializer_list+braced init
llvm-svn: 237625
|
|
Revision tags: llvmorg-3.6.1 |
|
| #
3eea677f |
| 11-May-2015 |
Peter Collingbourne <[email protected]> |
Unify sanitizer kind representation between the driver and the rest of the compiler.
No functional change.
Differential Revision: http://reviews.llvm.org/D9618
llvm-svn: 237055
|
|
Revision tags: llvmorg-3.6.1-rc1 |
|
| #
66242d6c |
| 23-Apr-2015 |
Justin Bogner <[email protected]> |
InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)
The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses else
InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)
The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly.
llvm-svn: 235664
show more ...
|
| #
f3e67de8 |
| 09-Apr-2015 |
Benjamin Kramer <[email protected]> |
[CodeGen] Do a more principled fix for PR231653, always use the inner type.
We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type
[CodeGen] Do a more principled fix for PR231653, always use the inner type.
We were still using the MaterializeTemporaryExpr's type to check if the transform is legal. Always use the inner Expr type.
llvm-svn: 234543
show more ...
|
| #
b2b81439 |
| 09-Apr-2015 |
Benjamin Kramer <[email protected]> |
[CodeGen] When promoting a reference temporary to a global use the inner type to fold it.
The MaterializeTemporaryExpr can have a different type than the inner expression, miscompiling the constant.
[CodeGen] When promoting a reference temporary to a global use the inner type to fold it.
The MaterializeTemporaryExpr can have a different type than the inner expression, miscompiling the constant. PR23165.
llvm-svn: 234499
show more ...
|
| #
2e80428d |
| 05-Apr-2015 |
David Blaikie <[email protected]> |
clang-format my last commit
(sorry, keep forgetting that)
llvm-svn: 234129
|
| #
1ed728c4 |
| 05-Apr-2015 |
David Blaikie <[email protected]> |
[opaque pointer type] More GEP API migrations
Looks like the VTable code in particular will need some work to pass around the pointee type explicitly.
llvm-svn: 234128
|
| #
17ea266b |
| 04-Apr-2015 |
David Blaikie <[email protected]> |
[opaque pointer type] More GEP API migrations
llvm-svn: 234109
|
| #
84146bee |
| 18-Mar-2015 |
Nick Lewycky <[email protected]> |
Fix the LLVM type used when lowering initializer list reference temporaries to global variables. Reapplies r232454 with fix for PR22940.
llvm-svn: 232579
|
|
Revision tags: llvmorg-3.5.2, llvmorg-3.5.2-rc1 |
|
| #
f9d865b0 |
| 17-Mar-2015 |
Hans Wennborg <[email protected]> |
Revert r232454 and r232456: "Fix the LLVM type used when lowering initializer list reference temporaries to global variables."
This caused PR22940.
llvm-svn: 232496
|
| #
cf191ada |
| 17-Mar-2015 |
Nick Lewycky <[email protected]> |
Fix the LLVM type used when lowering initializer list reference temporaries to global variables.
llvm-svn: 232454
|
| #
d2926c91 |
| 14-Mar-2015 |
Peter Collingbourne <[email protected]> |
Implement bad cast checks using control flow integrity information.
This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of t
Implement bad cast checks using control flow integrity information.
This scheme checks that pointer and lvalue casts are made to an object of the correct dynamic type; that is, the dynamic type of the object must be a derived class of the pointee type of the cast. The checks are currently only introduced where the class being casted to is a polymorphic class.
Differential Revision: http://reviews.llvm.org/D8312
llvm-svn: 232241
show more ...
|
| #
f8b86964 |
| 07-Mar-2015 |
Benjamin Kramer <[email protected]> |
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals."
I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inl
Reapply r231508 "CodeGen: Emit constant temporaries into read-only globals."
I disabled putting the new global into the same COMDAT as the function for now. There's a fundamental problem when we inline references to the global but still have the global in a COMDAT linked to the inlined function. Since this is only an optimization there may be other versions of the COMDAT around that are missing the new global and hell breaks loose at link time.
I hope the chromium build doesn't break this time :)
llvm-svn: 231564
show more ...
|
| #
cd8f0111 |
| 07-Mar-2015 |
Hans Wennborg <[email protected]> |
Revert r231508 "CodeGen: Emit constant temporaries into read-only globals."
This broke the Chromium build. Links were failing with messages like:
obj/dbus/libdbus_test_support.a(obj/dbus/dbus_test_
Revert r231508 "CodeGen: Emit constant temporaries into read-only globals."
This broke the Chromium build. Links were failing with messages like:
obj/dbus/libdbus_test_support.a(obj/dbus/dbus_test_support.mock_object_proxy.o):../../dbus/mock_object_proxy.cc:function dbus::MockObjectProxy::Detach(): warning: relocation refers to discarded section /usr/local/google/work/chromium/src/third_party/binutils/Linux_x64/Release/bin/ld.gold: error: treating warnings as errors
llvm-svn: 231541
show more ...
|
| #
3d8aa5c7 |
| 06-Mar-2015 |
Benjamin Kramer <[email protected]> |
CodeGen: Emit constant temporaries into read-only globals.
Instead of creating a copy on the stack just stash them in a private constant global. This saves both the copying overhead and the stack sp
CodeGen: Emit constant temporaries into read-only globals.
Instead of creating a copy on the stack just stash them in a private constant global. This saves both the copying overhead and the stack space, and gives the optimizer more room to constant fold.
This tries to make array temporaries more similar to regular arrays, they can't use the same logic because a temporary has no VarDecl to be bound to so we roll our own version here.
The original use case for this optimization was code like for (int i : {1, 2, 3, 4, 5, 6, 7, 8, 10}) foo(i); where without this patch (assuming that the loop is not unrolled) we would alloca an array on the stack, copy the 10 values over and iterate on that. With this patch we put the array in .text use it directly. Apart from that case this helps on virtually any passing of a constant std::initializer_list as a function argument.
Differential Revision: http://reviews.llvm.org/D8034
llvm-svn: 231508
show more ...
|
| #
ced8bdf7 |
| 25-Feb-2015 |
David Majnemer <[email protected]> |
Sema: Parenthesized bound destructor member expressions can be called
We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases.
This fixes PR22668.
llvm-svn: 230512
|
| #
3eff5f46 |
| 25-Feb-2015 |
Alexey Bataev <[email protected]> |
[OPENMP] Rename methods of OpenMPRuntime class. NFC.
llvm-svn: 230470
|