| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
These tests were creating a modules.idx file in my clang checkout, not
the build directory or temp.
All the other tests in this directory use -fmodules-cache-path=%t so
updated these to match.
llvm-svn: 243657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Copying the already existing code for x86 to ARM to set the correct CPU
features when using -mcpu=native. We can already detect the CPU name
but we were not setting the correct feature bits.
Moving fpu/hwdiv down to make sure they override whatever we set the
default to be.
No tests because this is native detection, and not all ARM-enabled builds
will hapen at a specific CPU, or even ARM. I have tested locally and it
works as expected.
Fixes PR12794.
llvm-svn: 243656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Replace the switch on instruction opcode with a switch on register size.
This way we don't need to update the switch statement when we add new
SMRD variants.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11601
llvm-svn: 243652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This function is never called. isReallyTriviallyReMaterializable() is
the function that should be implemented instead.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11620
llvm-svn: 243651
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Patch by Nitesh Jain and Jaydeep Patil with a small revision to use ABIs rather
than Architecture Revisions (which currently imply particular ABIs).
Fixes test_demangle.pass.cpp (PR24149).
Subscribers: mclow.lists, jaydeep, nitesh.jain, hans, cfe-commits
Differential Revision: http://reviews.llvm.org/D11483
llvm-svn: 243645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The memory-sanitizer build bot reported:
==5574== WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f03089e15f6 in
clang::Parser::TryAltiVecTokenOutOfLine(clang::DeclSpec&,
clang::SourceLocation, char const*&, unsigned int&, bool&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:6290:11
This is because the "Ident_pixel" variable was uninitialized
in the getLangOpts().ZVector case, but we'd still call into
clang::Parser::TryAltiVecTokenOutOfLine, which uses the variable.
The simplest fix for this without sprinkling !getLangOpts().ZVector
checks all over the code seems to be to just initialize the variable
to nullptr; this will then do the right thing on ZVector.
Checked in to unbreak the build bots.
llvm-svn: 243644
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the System Z vector built-in functions.
The API-defined header file has the name vecintrin.h.
The user-level functions are defined in the same style as the clang
version of altivec.h, making heavy use of the __overloadable__ and
__always_inline__ attributes. Where possible the functions expand to
generic operations rather than specific built-in functions, in the hope
that that form can be optimised better.
Where a built-in routine is specified to require an immediate integer
argument, the __enable_if__ attribute is used to verify the argument is
in fact constant and in the appropriate range.
Based on a patch by Richard Sandiford.
llvm-svn: 243643
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
|
| |
|
|
| |
llvm-svn: 243641
|
| |
|
|
|
|
|
|
| |
Update the debug info in the check-lines because the change in r243638
introduced a constant initialization before the prologue's end as part
of a register spill.
llvm-svn: 243640
|
| |
|
|
| |
llvm-svn: 243639
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D11595
llvm-svn: 243637
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
materialization.
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support it.
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
|
| |
|
|
|
|
|
|
|
|
|
| |
inline asm
This contains the test-case for r243630.
Patch by: marina.yatsina@intel.com
Differential Revision: http://reviews.llvm.org/D11513
llvm-svn: 243632
|
| |
|
|
|
|
|
|
|
| |
inline asm
Patch by: marina.yatsina@intel.com
Differential Revision: http://reviews.llvm.org/D11512
llvm-svn: 243630
|
| |
|
|
| |
llvm-svn: 243628
|
| |
|
|
|
|
|
| |
This is used by the AMD x86 OpenCL implementation
to change some ABI details on Windows and Linux.
llvm-svn: 243627
|
| |
|
|
|
|
| |
section, and __RLD_MAP symbol
llvm-svn: 243626
|
| |
|
|
| |
llvm-svn: 243625
|
| |
|
|
|
|
|
| |
I think I was isolating the failure in the last RUN: line during
development, and forgot to re-enable the others.
llvm-svn: 243624
|
| |
|
|
| |
llvm-svn: 243623
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 243621
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
treated as a string
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 243615
|
| |
|
|
| |
llvm-svn: 243614
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
tables. We don't need to store the data length twice.
llvm-svn: 243612
|
| |
|
|
|
|
| |
dfsan), add a test
llvm-svn: 243611
|
| |
|
|
|
|
| |
sanitizers. Hide the declaration and the calls in better macros
llvm-svn: 243610
|
| |
|
|
| |
llvm-svn: 243609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
extend the memcmp fuzzer test
llvm-svn: 243603
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
fuzzing. More hooks will be added later. So far this is a Linux-only feature
llvm-svn: 243601
|
| |
|
|
|
|
|
| |
It looks like we were somehow relying somewhere on removing 'foo/./bar'
but *not* 'foo/../foo/bar'. Currently investigating.
llvm-svn: 243600
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
instruction-type check; NFC
This makes it simpler to add instruction types that don't depend on fast-math.
llvm-svn: 243596
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 243593
|
| |
|
|
|
|
|
|
|
|
| |
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
|