declarations.
This commit ensures that the correct record type is printed out for the
using declarations that represent C++ inherited constructors.
It fixes a regression introduced in r274049 which changed the name that's
stored in the using declarations that correspond to inherited constructors.
Differential Revision: https://reviews.llvm.org/D25131
llvm-svn: 283105
declarations.
This commit ensures that the correct record type is printed out for the
using declarations that represent C++ inherited constructors.
It fixes a regression introduced in r274049 which changed the name that's
stored in the using declarations that correspond to inherited constructors.
Differential Revision: https://reviews.llvm.org/D25131
llvm-svn: 283102
The cmake files install directory has been changed to
${prefix}/lib/cmake/llvm since r259821. Searching cmake modules in
${prefix}/share/llvm/cmake will result in fatal errors.
This commit fixes the out-of-tree build by changing the CMake module
search path to: "$(llvm-config --obj-root)/lib/cmake/llvm"
llvm-svn: 283100
Summary: Added 6 new target hooks for the vectorizer in order to filter types, handle size constraints and decide how to split chains.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, mzolotukhin, wdng, llvm-commits, nhaehnle
Differential Revision: https://reviews.llvm.org/D24727
llvm-svn: 283099
library call to __aeabi_uidivmod. This is an improved implementation of
r280808, see also D24133, that got reverted because isel was stuck in a loop.
That was caused by the optimisation incorrectly triggering on i64 ints, which
shouldn't happen because there is no 64bit hwdiv support; that put isel's type
legalization and this optimisation in a loop. A native ARM compiler and testing
now shows that this is fixed.
Patch mostly by Pablo Barrio.
Differential Revision: https://reviews.llvm.org/D25077
llvm-svn: 283098
Case was revealed by id_000010,sig_08,src_000000,op_havoc,rep_4 from PR30540.
Out implementation uses uint32 for storing section alignment value,
what seems reasonable, though if value exceeds 32 bits bounds we have
truncation and final value of 0.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25082
llvm-svn: 283097
When there is 'do { } while (0);' in the code the ExplodedGraph and UnoptimizedCFG did not match.
Differential Revision: https://reviews.llvm.org/D24759
llvm-svn: 283095
Highlight code clones referenced by the warning message with the help of
the extra notes feature recently introduced in r283092.
Change warning text to more clang-ish. Remove suggestions from the copy-paste
error checker diagnostics, because currently our suggestions are strictly 50%
wrong (we do not know which of the two code clones contains the error), and
for that reason we should not sound as if we're actually suggesting this.
Hopefully a better solution would bring them back.
Make sure the suspicious clone pair structure always mentions
the correct variable for the second clone.
Differential Revision: https://reviews.llvm.org/D24916
llvm-svn: 283094
The report is now highlighting instance variables and properties
referenced by the warning message with the help of the
extra notes feature recently introduced in r283092.
Differential Revision: https://reviews.llvm.org/D24915
llvm-svn: 283093
These diagnostics are separate from the path-sensitive engine's path notes,
and can be added manually on top of path-sensitive or path-insensitive reports.
The new note diagnostics would appear as note:-diagnostic on console and
as blue bubbles in scan-build. In plist files they currently do not appear,
because format needs to be discussed with plist file users.
The analyzer option "-analyzer-config notes-as-events=true" would convert
notes to normal path notes, and put them at the beginning of the path.
This is a temporary hack to show the new notes in plist files.
A few checkers would be updated in subsequent commits,
including tests for this new feature.
Differential Revision: https://reviews.llvm.org/D24278
llvm-svn: 283092
search loop, by Andrey Tischenko
PR27136 shows failure to hoist constant out of loop. This test is used
as start point to fix the failure: it shows the current state of codegen
and discovers what should be fixed
Differential Revision: https://reviews.llvm.org/D25097
llvm-svn: 283091
Summary:
lit's `OneCommandFileTest` class implements an abstract method that
raises if called. However, it raises by referencing an undefined
symbol. Instead, raise explicitly by throwing a `NotImplementedError`.
This is clearer, and appeases Python linters.
Patch By Brian Gesiak!
Reviewers: ddunbar, echristo, beanz
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25170
llvm-svn: 283090
Summary:
In Python, `None` is a singleton, so checking whether a variable is
`None` may be done with `is` or `is not`. This has a slight advantage
over equiality comparisons `== None` and `!= None`, since `__eq__` may
be overridden in Python to produce sometimes unexpected results.
Using `is None` and `is not None` is also recommended practice in
https://www.python.org/dev/peps/pep-0008:
> Comparisons to singletons like `None` should always be done with `is` or
> `is not`, never the equality operators.
Patch by Brian Gesiak!
Reviewers: ddunbar, echristo, beanz
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25168
llvm-svn: 283088
The PPC branch-selection pass, which performs branch relaxation, needs to
account for the padding that might be introduced to satisfy block alignment
requirements. We were assuming that the first block was at offset zero (i.e.
had the alignment of the function itself), but under the ELFv2 ABI, a global
entry function prologue is added to the first block, and it is a
two-instruction sequence (i.e. eight-bytes long). If the function has 16-byte
alignment, the fact that the first block is eight bytes offset from the start
of the function is relevant to calculating where padding will be added in
between later blocks.
Unfortunately, I don't have a small test case.
llvm-svn: 283086
I don't know for sure that we truly needs this, but its the only vector load that isn't rematerializable. Making it consistent allows it to not be a special case in the td files.
llvm-svn: 283083
These are missing dependencies that have been exposed in builds as a result of my change to make lldb libraries depend on CLANG_TABLEGEN_TARGETS instead of libclang.
llvm-svn: 283081
This was first landed in rL283058 and subsequenlty reverted since a
change this depends on (rL283057) was buggy and had to be reverted.
llvm-svn: 283079
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.
An earlier version of this change was landed as rL283057 which had a
use-after-free bug. This new version has a fix for that bug, and a (C++
unittests/) test case that would have triggered it rL283057.
llvm-svn: 283078
Install the 'clang-cpp' symlink used to spawn the preprocessor. The code
handling this suffix is already included in Driver. FreeBSD is already
creating such a symlink in ports, and a similar one was requested
by Gentoo/FreeBSD team. The goal is to handle software that takes a C
preprocessor via a variable but does not handle passing options
correctly (i.e. 'clang -E' does not work).
Bug: https://bugs.gentoo.org/478810
Differential Revision: https://reviews.llvm.org/D25161
llvm-svn: 283075
Preemptively scrubbing these to avoid a bot fail as in PR30443:
https://llvm.org/bugs/show_bug.cgi?id=30443
I'm nearly done with a patch to fix these cases, so not trying very
hard to do better for the temporary win.
I plan to use better checks than what the script produces for the vectorized cases.
llvm-svn: 283072
To allow broadcast loads of a non-zero'th vector element, lowerVectorShuffleAsBroadcast can replace a load with a new load with an adjusted address, but unfortunately we weren't ensuring that the new load respected the same dependencies.
This patch adds a TokenFactor and updates all dependencies of the old load to reference the new load instead.
Bug found during internal testing.
Differential Revision: https://reviews.llvm.org/D25039
llvm-svn: 283070
* Use lexical binding, as recommended for new libraries.
* Fix customization variable (set correct group and type).
* Create a new customization group for the library.
* Autoload the main clang-rename command so that users don't have to explicitly load the library.
* Correctly translate between file and buffer positions using bufferpos-to-filepos (if available) or a fallback.
* Don't invoke the shell, it's not necessary and adds complexity.
* Save clang-rename output in a buffer and display that on failure.
* Save all buffers before calling clang-rename. This is required anyway and prevents data loss when the buffer is later reverted.
* In revert-buffer, use keywords instead of t for Boolean arguments to improve readability.
* Don't reset buffer modes when reverting.
* Emacs treats the character after a symbol as part of the symbol, while clang-rename doesn't; resolve this inconsistency.
* Formatting.
Patch by Philipp Stephani!
Reviewers: omtcyfz
Differential Revision: https://reviews.llvm.org/D25156
llvm-svn: 283067
Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.
Patch mostly by EricWF.
Reviewers: rnk, cfe-commits, rsmith, EricWF
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D25130
llvm-svn: 283064
Reapplying the patch after modifying the test case.
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend.
https://llvm.org/bugs/show_bug.cgi?id=30341
This patch disables alias to available_externally definitions.
Reviewers: eugenis, rsmith
Differential Revision: https://reviews.llvm.org/D24682
llvm-svn: 283063
They've broken the sanitizer-bootstrap bots. Reverting while I investigate.
Original commit messages:
r283057: "[ConstantRange] Make getEquivalentICmp smarter"
r283058: "[SCEV] Rely on ConstantRange instead of custom logic; NFCI"
llvm-svn: 283062
Enable soft-float support on PPC64, as the backend now supports it. Also, the
backend now uses -hard-float instead of +soft-float, so set the target features
accordingly.
Fixes PR26970.
llvm-svn: 283061
This change enables soft-float for PowerPC64, and also makes soft-float disable
all vector instruction sets for both 32-bit and 64-bit modes. This latter part
is necessary because the PPC backend canonicalizes many Altivec vector types to
floating-point types, and so soft-float breaks scalarization support for many
operations. Both for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware floating-point
also disables vector instructions (embedded targets without hardware floating
point support are unlikely to have Altivec, etc. and operating system kernels
desiring not to use floating-point registers to lower syscall cost are unlikely
to want to use vector registers either). If someone needs this to work, we'll
need to change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is enabled,
hardware floating-point support needs to be expressed as a positive feature,
like the others, and not a negative feature, because target features cannot
have dependencies on the disabling of some other feature. So +soft-float has
now become -hard-float.
Fixes PR26970.
llvm-svn: 283060
Sjoerd Meijer