| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
This patch replaces all uses of __libc_malloc and friends with the internal allocator.
It seems that the only reason why we have calls to __libc_malloc in the first place was the lack of the internal allocator at the time. Using the internal allocator will also make sure that the system allocator is never used (this is the same behavior as ASan), and we don’t have to worry about working with unknown pointers coming from the system allocator.
Differential Revision: http://reviews.llvm.org/D21025
llvm-svn: 271916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some known issues are:
When "head" include instructions that involve branching, the "cut and paste" approach may break down in a way that function interception still work but calling back the original function does not work.
The jmp [rip -8] saves some bytes in the "head" but finding the safe zone of 0xCC is not implemented yet. So it may stomp on preceding codes.
The shadow offset is not working yet on Win64. More complexity maybe involved since there are some differences regarding virtual address space between Window 8 and Windows 8.1/10.
Patch by: Wang Wei
Differential Revision: http://reviews.llvm.org/D20884
llvm-svn: 271915
|
| |
|
|
|
|
|
|
|
| |
Reapply r271907 with a fix for the compiler error with gcc about specializing
clang::ento::ProgramStateTrait in a different namespace.
Differential Revision: http://reviews.llvm.org/D12761
llvm-svn: 271914
|
| |
|
|
| |
llvm-svn: 271913
|
| |
|
|
| |
llvm-svn: 271911
|
| |
|
|
|
|
|
| |
For pack TemplateArguments, visualize all of the items in the pack
Visualize a TemplateArgumentList as a template argument list. E.g., <int, double>
llvm-svn: 271910
|
| |
|
|
|
|
|
| |
This reverts commit r271907. It broke a bunch of bots with compile errors
about specializations in different namespaces.
llvm-svn: 271909
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r271810 ( http://reviews.llvm.org/rL271810 ), I loosened the check
above this to work for any Constant rather than ConstantInt. AFAICT,
that part makes sense if we can determine that the shrunken/extended
constant remained equal. But it doesn't make sense for this later
transform where we assume that the constant DID change.
This could assert for a ConstantExpr:
https://llvm.org/bugs/show_bug.cgi?id=28011
And it could be wrong for a vector as shown in the added regression test.
llvm-svn: 271908
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a static analysis checker to check for the correct usage of the
MPI API in C and C++.
3 path-sensitive checks are included:
- Double nonblocking: Double request usage by nonblocking calls
without intermediate wait.
- Missing wait: Nonblocking call without matching wait.
- Unmatched wait: Waiting for a request that was never used by a
nonblocking call.
Examples of how to use the checker can be found
at https://github.com/0ax1/MPI-Checker
Reviewers: zaks.anna
A patch by Alexander Droste!
Differential Revision: http://reviews.llvm.org/D12761
llvm-svn: 271907
|
| |
|
|
|
|
|
|
| |
This is a very simple optimization that gets about 10% speedup for certain programs. We’re currently storing the pointer to the main thread’s ThreadState, but we can store the state directly in a static variable, which avoid the load acquire.
Differential Revision: http://reviews.llvm.org/D20910
llvm-svn: 271906
|
| |
|
|
|
|
|
|
| |
Somehow, in r271049, ASan lit tests and unit tests were removed from “check-all”. Doesn’t seem intentional, let’s fix it.
Differential Revision: http://reviews.llvm.org/D21017
llvm-svn: 271905
|
| |
|
|
| |
llvm-svn: 271904
|
| |
|
|
| |
llvm-svn: 271903
|
| |
|
|
|
|
|
|
|
| |
Mention that the code coverage tool becomes less precise whenever
unpredictable changes in control flow occur.
Thanks to Sean Silva for pointing this out!
llvm-svn: 271902
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21008
llvm-svn: 271901
|
| |
|
|
|
|
|
|
|
|
|
|
| |
src2 == VCC.
Another step for unification llvm assembler/disassembler with sp3.
Besides, CodeGen output is a bit improved, thus changes in CodeGen tests.
Assembler/Disassembler tests updated/added.
Differential Revision: http://reviews.llvm.org/D20796
llvm-svn: 271900
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Because PIE executables have an e_type of llvm::ELF::ET_DYN,
they are not of type eTypeExecutable, and were being removed
when svr4 packets were used.
Reviewers: clayborg, ADodds, tfiala, sas
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20990
llvm-svn: 271899
|
| |
|
|
|
|
|
|
|
| |
This patch refactors the code generation for divisions. This allows to
always generate a shift for a power-of-two division and to utilize
information about constant divisors in order to truncate the result
type.
llvm-svn: 271898
|
| |
|
|
|
|
| |
chars. Thanks to STL@microsoft for the report.
llvm-svn: 271897
|
| |
|
|
|
|
|
|
|
| |
macro.
It is not easy to tell where to do the suggestion and whether the
suggestion will be correct.
llvm-svn: 271896
|
| |
|
|
|
|
|
| |
Contributed-by: Aditya Kumar <hiraditya@msn.com>
Differential Revision: http://reviews.llvm.org/D20953
llvm-svn: 271895
|
| |
|
|
|
|
|
|
|
| |
We now generate runtime checks __after__ the SCoP code generation and
not before, though they are still inserted at the same position int
the code. This allows to modify the runtime check during SCoP code
generation.
llvm-svn: 271894
|
| |
|
|
|
|
|
|
| |
match was the ld.elf_so that should be matched in a second step. Add one
of the ever-present-but-irrelevant-for-this-test arguments to the
pattern to force matching the right argument.
llvm-svn: 271893
|
| |
|
|
| |
llvm-svn: 271892
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21013
llvm-svn: 271891
|
| |
|
|
| |
llvm-svn: 271890
|
| |
|
|
| |
llvm-svn: 271889
|
| |
|
|
|
|
|
|
|
| |
IntToPtr and PtrToInt instructions are basically no-ops that we can handle as
such. In order to generate them properly as parameters we had to improve the
ScopExpander, though the change is the first in the direction of a more
aggressive scalar synthetization.
llvm-svn: 271888
|
| |
|
|
|
|
| |
Found by clang-tidy's misc-assert-side-effect.
llvm-svn: 271887
|
| |
|
|
| |
llvm-svn: 271886
|
| |
|
|
| |
llvm-svn: 271885
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
triples.
Summary:
32-bit CPU's default to O32. 64-bit CPU's default to N64. The default CPU
(mips32r2/mips64r2) still depends on the arch so there's no functional
change when the CPU isn't specified but commands like:
clang -target mips-mti-linux-gnu -mips64r2
will now default to a 64-bit ABI like our gcc toolchains do* instead of
asserting in the backend**.
Other vendors (including Triple::UnknownVendor) still derive the default
ABI from the arch.
* Although not the same one as our gcc toolchains, clang has historically
defaulted to N64 where gcc defaults to N32.
** Mixing O32 and a 64-bit CPU causing assertions is a long-standing bug.
Reviewers: atanasyan
Subscribers: sdardis, cfe-commits
Differential Revision: http://reviews.llvm.org/D21016
llvm-svn: 271884
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: make header guard identification stricter with Lexer.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D20959
llvm-svn: 271883
|
| |
|
|
| |
llvm-svn: 271882
|
| |
|
|
| |
llvm-svn: 271881
|
| |
|
|
| |
llvm-svn: 271880
|
| |
|
|
| |
llvm-svn: 271879
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We now use the minimal necessary bit width for the generated code. If
operations might overflow (add/sub/mul) we will try to adjust the types in
order to ensure a non-wrapping computation. If the type adjustment is not
possible, thus the necessary type is bigger than the type value of
--polly-max-expr-bit-width, we will use assumptions to verify the computation
will not wrap. However, for run-time checks we cannot build assumptions but
instead utilize overflow tracking intrinsics.
llvm-svn: 271878
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reviewers: atanasyan
Subscribers: cfe-commits, sdardis
Differential Revision: http://reviews.llvm.org/D20963
llvm-svn: 271877
|
| |
|
|
|
|
|
|
|
|
|
|
| |
return NULL for an invalid register.
The unwind logic asks for the "return address register" which doesn't exist
on x86/x86_64, returns -1 and calls this with -1 as a parameter, ends up
out of scope of the array bounds for g_register_infos and later SIGSEGVs
on accessing. This now matches the other GetRegisterInfoAtIndex for
other platforms.
llvm-svn: 271876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
setABI() is still tied to the Arch component of the Triple to preserve existing
behaviour.
Reviewers: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20961
llvm-svn: 271875
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
index.
.gnu.version should have sh_link field initialized with index of DynSymTab section.
GNU documentation looks misses that, but Sun docs mention it, according to
https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter6-54676/index.html
versym sh_link is indeed supposed to point to the .dynsym section.
Binutils readelf tool also relies on that:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=binutils/readelf.c;h=b6454d353279dc57745cd5a2d68b5f3f69f8e17c;hb=5522f910cb539905d6adfdceab208ddfa5e84557#l9988
Both gold/bfd do the same + after this patch I am able to see this section in readelf output, was unable before in my case.
Differential revision: http://reviews.llvm.org/D20956
llvm-svn: 271874
|
| |
|
|
|
|
| |
the other palignr builtins, but with a select to handle masking.
llvm-svn: 271873
|
| |
|
|
|
|
| |
of vector shuffle and select.
llvm-svn: 271872
|
| |
|
|
|
|
|
|
|
| |
With CMP0056, try_compile() uses also CMAKE_EXE_LINKER_FLAG.
It caused mismatch between CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS, to fail to examine CXX_SUPPORTS_CXX11 with -m32.
FYI, before this, try_compile() tries without -m32 regardless of LLVM_BUILD_32_BITS.
llvm-svn: 271871
|
| |
|
|
| |
llvm-svn: 271870
|
| |
|
|
| |
llvm-svn: 271869
|
| |
|
|
|
|
|
|
| |
of OptimizeLayer for CompileLayer in Chapter 2.
Hopefully this will read a little more clearly.
llvm-svn: 271868
|
| |
|
|
| |
llvm-svn: 271867
|
| |
|
|
|
|
|
|
|
| |
Now it gives the StmtClass of the Expr as well as the type. It's still
a long way from full visualization of expressions, but I have found
that having the class really helps when debugging, so definitely
worth submitting.
llvm-svn: 271866
|