- Jul 30, 2015
-
-
NAKAMURA Takumi authored
llvm-svn: 243639
-
Vasileios Kalintiris authored
Summary: This hidden option would disable code generation through FastISel by default. It was removed from the available options and from the Fast-ISel tests that required it in order to run the tests. Reviewers: dsanders Subscribers: qcolombet, llvm-commits Differential Revision: http://reviews.llvm.org/D11610 llvm-svn: 243638
-
Tamas Berghammer authored
Differential revision: http://reviews.llvm.org/D11595 llvm-svn: 243637
-
Vasileios Kalintiris authored
Summary: Previously, we would sign-extend non-boolean negative constants and zero-extend otherwise. This was problematic for PHI instructions with negative values that had a type with bitwidth less than that of the register used for materialization. More specifically, ComputePHILiveOutRegInfo() assumes the constants present in a PHI node are zero extended in their container and afterwards deduces the known bits. For example, previously we would materialize an i16 -4 with the following instruction: addiu $r, $zero, -4 The register would end-up with the 32-bit 2's complement representation of -4. However, ComputePHILiveOutRegInfo() would generate a constant with the upper 16-bits set to zero. The SelectionDAG builder would use that information to generate an AssertZero node that would remove any subsequent trunc & zero_extend nodes. In theory, we should modify ComputePHILiveOutRegInfo() to consult target-specific hooks about the way they prefer to materialize the given constants. However, git-blame reports that this specific code has not been touched since 2011 and it seems to be working well for every target so far. Reviewers: dsanders Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11592 llvm-svn: 243636
-
Alexey Bataev authored
OpenMP 4.1 introduces optional argument '(n)' for 'ordered' clause, where 'n' is a number of loops that immediately follow the directive. 'n' must be constant positive integer expressions and it must be less or equal than the number of the loops in the resulting loop nest. Patch adds parsing and semantic analysis for this optional argument. llvm-svn: 243635
-
Daniel Sanders authored
Summary: Mips doesn't implement unw_getcontext() or libunwind::Registers_*::jumpto() yet so we must disable libunwind for this release. Reviewers: hans Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11563 llvm-svn: 243633
-
Michael Kuperstein authored
This contains the test-case for r243630. Patch by: marina.yatsina@intel.com Differential Revision: http://reviews.llvm.org/D11513 llvm-svn: 243632
-
Michael Kuperstein authored
Patch by: marina.yatsina@intel.com Differential Revision: http://reviews.llvm.org/D11512 llvm-svn: 243630
-
Tamas Berghammer authored
llvm-svn: 243628
-
Matt Arsenault authored
This is used by the AMD x86 OpenCL implementation to change some ABI details on Windows and Linux. llvm-svn: 243627
-
Simon Atanasyan authored
llvm-svn: 243626
-
Sean Silva authored
llvm-svn: 243625
-
Sean Silva authored
I think I was isolating the failure in the last RUN: line during development, and forgot to re-enable the others. llvm-svn: 243624
-
Asaf Badouh authored
llvm-svn: 243623
-
Mohit K. Bhakkad authored
Patch by Nitesh Jain Reviewers: clayborg, ovyalov. Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar, emaste, lldb-commits. Differential Revision: http://reviews.llvm.org/D11562 llvm-svn: 243622
-
Ilia K authored
llvm-svn: 243621
-
Mohit K. Bhakkad authored
Patch by Nitesh Jain Reviewers: clayborg, ovyalov. Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar, emaste, lldb-commits. Differential Revision: http://reviews.llvm.org/D11176 llvm-svn: 243620
-
Ilia K authored
Summary: Currently if the "first child" of the pointer is a char type then the pointer is displayed as a string. This test succeeds incorrectly when the pointer is to a structured type with a char type as its first field. Fix this by switching the test to retrieve the pointee type and checking that it is a char type. Reviewers: abidh, ChuckR, ki.stfu Subscribers: greggm, lldb-commits Differential Revision: http://reviews.llvm.org/D11488 llvm-svn: 243619
-
Jaydeep Patil authored
SUMMARY: The patch creates Unix Signals based on target architecture. For MIPS it creates MipsLinuxSignals. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, lldb-commits Differential Revision: http://reviews.llvm.org/D11455 llvm-svn: 243618
-
Adam Nemet authored
The reason I was passing this vector by value in the constructor so that I wouldn't have to copy when initializing the corresponding member but then I forgot the std::move. The use-case is LoopDistribution which filters the checks then std::moves it to LoopVersioning's constructor. With this interface we can avoid any copies. llvm-svn: 243616
-
Nico Weber authored
llvm-svn: 243615
-
Richard Smith authored
llvm-svn: 243614
-
Adam Nemet authored
Before, we were passing the pointer partitions to LAA. Now, we get all the checks from LAA and filter out the checks within partitions in LoopDistribution. This effectively concludes the steps to move filtering memchecks from LAA into its clients. There is still some cleanup left to remove the unused interfaces in LAA that still take PtrPartition. (Moving this functionality to LoopDistribution also requires needsChecking on pointers to be made public.) llvm-svn: 243613
-
Richard Smith authored
[modules] Remove redundant information written into DeclContext name lookup tables. We don't need to store the data length twice. llvm-svn: 243612
-
Kostya Serebryany authored
llvm-svn: 243611
-
Kostya Serebryany authored
[sanitizer] add a weak hook for strncmp interceptor, both to dfsan and other sanitizers. Hide the declaration and the calls in better macros llvm-svn: 243610
-
Lang Hames authored
llvm-svn: 243609
-
Hans Wennborg authored
Clang will not define __i686__, even when the target triple is i686, without -march=i686. With this patch, the compiler-rt build will successfully detect that Clang can target i686. The open_memstream.cc test is a little funny. Before my patch, it was invoked with "-m32 -m64". To make it work after my -march change, I had to add '-march=x86-64'. Differential Revision: http://reviews.llvm.org/D11618 llvm-svn: 243604
-
Kostya Serebryany authored
[libFuzzer] implement memcmp hook for data-flow-guided fuzzing (w/o dfsan), extend the memcmp fuzzer test llvm-svn: 243603
-
Sean Silva authored
We currently don't canonicalize paths in the preprocessed files. But we do when writing to PCH. This causes a discrepancy on Windows with the test below. This test fails even on unix if you change the test to use `%S//preprocess.h`. I am led to conclude that the invariant that this test was intending to test has not been upheld for a while (and may never have been). llvm-svn: 243602
-
Kostya Serebryany authored
[sanitizer] add a weak hook for memcmp interceptor, to be used primarily for fuzzing. More hooks will be added later. So far this is a Linux-only feature llvm-svn: 243601
-
Sean Silva authored
It looks like we were somehow relying somewhere on removing 'foo/./bar' but *not* 'foo/../foo/bar'. Currently investigating. llvm-svn: 243600
-
Alexey Samsonov authored
Let me tell you a story. Suppose you want to build your project (e.g. LLVM) with CMake 2.8, Clang and AddressSanitizer. You also want to ensure that Clang is fresh enough and check that CMAKE_CXX_COMPILER_VERSION is 3.1+. This check would fail - CMake would fail to correctly calculate compiler version if you pass CMAKE_CXX_FLAGS=-fsanitize=address. The problem is funky compiler version calculation in CMakeDetermineCompilerId.cmake module: it compiles the sample source file with provided compiler and compile flags, runs "strings" and greps for "INFO:" ASCII strings contained on the executable to fetch "INFO:compiler", "INFO:compiler_version" etc. It limits the output of grep to just 4 lines. Unfortunately, if your executable was built with ASan, it would also contain an ASCII string INFO: %s ignores mlock/mlockall/munlock/munlockall and INFO:compiler_version string would never be parsed. All of the above actually happened after r243574 when we tried to configure libcxx with just-built Clang with TSan/MSan, and the version check mentioned above failed in HandleLLVMOptions.cmake (╯°□°)╯.~.┻━┻ llvm-svn: 243599
-
Pete Cooper authored
This was fallout from r243581. Turns out C++14 has make_reverse_iterator. Thanks to Filipe and David for the quick fix suggestion. llvm-svn: 243598
-
Sean Silva authored
Also fix completely broken and untested code which was hiding the primary bug. The !LLVM_ON_UNIX branch of the ifdef was actually a no-op. I ran into this in the wild. It was causing failures in our SDK build. Ideally we'd have a perfect llvm::sys::fs::canonical, but at least this is a step in the right direction, and fixes an obviously broken case. In some sense the test case I've added here is an integration test. We should have these routines thoroughly unit tested in llvm::sys::fs. llvm-svn: 243597
-
Sanjay Patel authored
This makes it simpler to add instruction types that don't depend on fast-math. llvm-svn: 243596
-
Kostya Serebryany authored
[asan,tsan,msan] move the memcmp interceptor from asan/tsan to sanitizer_common. This may potentially lead to more reports from msan as it now sees the reads inside memcmp. To disable, use the flag intercept_memcmp=0. Likewise, it may potentially cause new races to appear due to more strict memcmp checking (flag strict_memcmp=1) llvm-svn: 243595
-
Richard Trieu authored
Without DR1579 implemented, the only case for -Wredundant-move is for a parameter being returned with the same type as the function return type. Also include a check to verify that the move constructor will be used by matching nodes in the AST dump. llvm-svn: 243594
-
Eric Fiselier authored
llvm-svn: 243593
-
Richard Smith authored
UsingShadowDecls over other declarations of the same entity in the lookup results. This ensures that we build correct redeclaration chains for the UsingShadowDecls (otherwise we could see assertions and other misbehavior in modules builds, when merging combines multiple redeclaration chains for the same entity from the same module into one chain). llvm-svn: 243592
-