| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
warnings reported.
I started this patch as a refactoring, tried to make a helper for
getting symbol names, similar to how we get section names
used in warning messages.
So this patch cleanups the code and fixes an issue: symbol names
in warning messages were not demangled.
Differential revision: https://reviews.llvm.org/D68012
llvm-svn: 372867
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917
As discussed there, we want to have fast-math-flags be a property of an FP value
because the alternative (having them on things like fcmp) leads to logical
inconsistency such as:
https://bugs.llvm.org/show_bug.cgi?id=38086
The earlier patch for select made almost no practical difference because most
unoptimized conditional code begins life as a phi (based on what I see in clang).
Similarly, I don't expect this patch to do much on its own either because
SimplifyCFG promptly drops the flags when converting to select on a minimal
example like:
https://bugs.llvm.org/show_bug.cgi?id=39535
But once we have this plumbing in place, we should be able to wire up the FMF
propagation and start solving cases like that.
The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a
regression in a LoopVectorize test. We are intersecting the FMF of any
FPMathOperator there, so if a phi is not properly annotated, new math
instructions may not be either. Once we fix the propagation in SimplifyCFG, it
may be safe to remove that hack.
Differential Revision: https://reviews.llvm.org/D67564
llvm-svn: 372866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The --bytes option uses the phrase "printable ASCII characters", but the
description section used simply "printable characters". To avoid any
confusion about locale impacts etc, this change adopts the former's
phrasing in both places. It also fixes a minor grammar issue in the
description.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D68016
llvm-svn: 372865
|
|
|
|
|
|
|
|
|
| |
Main changes are mostly wording of some options, but this change also
fixes a switch reference so that a link is created and moves
--strip-sections into the ELF-specific area since it is only supported
for ELF currently.
llvm-svn: 372864
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Decl::printQualifiedName
Summary:
To be used in clangd, e.g. in D66647.
Currently the alternative to this function is doing string manipulation on results of `printQualifiedName`, which is
hard-to-impossible to get right in presence of template arguments.
Reviewers: kadircet, aaron.ballman
Reviewed By: kadircet, aaron.ballman
Subscribers: aaron.ballman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67825
llvm-svn: 372863
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I was recently surprised to learn that there is a total of 2 (two) users
of the register info definitions contained in the ABI plugins. Yet, the
defitions themselves span nearly 10kLOC.
The two users are:
- dwarf expression pretty printer
- the mechanism for augmenting the register info definitions obtained
over gdb-remote protocol (AugmentRegisterInfoViaABI)
Both of these uses need the DWARF an EH register numbers, which is
information that is already available in LLVM. This patch makes it
possible to do so.
It adds a GetMCRegisterInfo method to the ABI class, which every class
is expected to implement. Normally, it should be sufficient to obtain
the definitions from the appropriate llvm::Target object (for which I
provide a utility function), but the subclasses are free to construct it
in any way they deem fit.
We should be able to always get the MCRegisterInfo object from llvm,
with one important exception: if the relevant llvm target was disabled
at compile time. To handle this, I add a mechanism to disable the
compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD
cmake setting. This ensures all our existing are able to create their
MCRegisterInfo objects.
The new MCRegisterInfo api is not used yet, but the intention is to make
use of it in follow-up patches.
Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha
Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits
Differential Revision: https://reviews.llvm.org/D67965
llvm-svn: 372862
|
|
|
|
|
|
|
|
|
|
| |
GetRawLineUntilCursor
They both return the same result as another function (GetCursorArgumentPrefix
and GetRawLine). They were only added because the old API allowed to look
(in theory) behind the cursor position which is no longer possible.
llvm-svn: 372861
|
|
|
|
| |
llvm-svn: 372860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allows to simplify pending code tweaks:
- the upcoming DefineInline tweak (D66647)
- remove using declaration (D56612)
- qualify name under cursor (D56610)
Another potential future application is simplifying semantic highlighting.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: mgrang, jfb, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67826
llvm-svn: 372859
|
|
|
|
|
|
|
|
|
| |
This is the only legitimate use we currently have for modifying
a CompletionRequest. Add a utility function for this purpose
and remove the remaining setters which go against the idea of
having an immutable CompletionRequest.
llvm-svn: 372858
|
|
|
|
|
|
|
|
| |
Summary of changes:
- Updated to reflect recent changes in assembler;
- Minor bugfixing and improvements.
llvm-svn: 372857
|
|
|
|
| |
llvm-svn: 372856
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up for D67757,
which allows to describe .stack_sizes sections with a new
YAML syntax.
Differential revision: https://reviews.llvm.org/D67759
llvm-svn: 372855
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we can't use unique suffixes in section names to describe
stack sizes sections. E.g. '.stack_sizes [1]' will be treated as a regular section.
This happens because we recognize stack sizes section by name and
do not yet drop the suffix before the check.
The patch fixes it.
Differential revision: https://reviews.llvm.org/D68018
llvm-svn: 372853
|
|
|
|
|
|
|
| |
This should fix buildbot errors like this one:
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/10997
llvm-svn: 372852
|
|
|
|
|
|
|
|
| |
The cursor position is always at the end of the current argument (as the
argument cut off after the cursor position). So this code is a no-op and
can be removed.
llvm-svn: 372851
|
|
|
|
| |
llvm-svn: 372850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mmap()ed variable
ld64 in the macOS 10.15 SDK gives __DATA a maxprot of 3, meaning it
can't be made executable at runtime by default.
Change clear_cache_test.c to use mmap()ed data that's mapped as writable
and executable from the beginning, instead of trying to mprotect()ing a
__DATA variable as executable. This fixes the test on macOS with the
10.15 SDK.
PR43407.
Differential Revision: https://reviews.llvm.org/D67929
llvm-svn: 372849
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Use symbolic constants for the platform identifiers rather than replicating them
> locally.
This broke the build of LLDB on Windows, see
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9182 which
fails with e.g.
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(96): error C2059: syntax error: 'constant'
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(96): error C3805: 'constant': unexpected token, expected either '}' or a ','
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(128): error C2059: syntax error: 'constant'
...
llvm-svn: 372847
|
|
|
|
| |
llvm-svn: 372846
|
|
|
|
|
|
|
|
|
|
| |
It is a follow-up requested in the review comment
for D67757. Allows to use Content + Size or just Size
when describing .stack_sizes sections in YAML document
Differential revision: https://reviews.llvm.org/D67958
llvm-svn: 372845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specializations are inline""
This work-around was necessary to handle standard library headers in
Visual Studio 2019 16.2. Now that 16.3 has shipped to stable, we can
remove it.
> Re-commit r363191 "[MS] Pretend constexpr variable template specializations are inline"
>
> While the next Visual Studio update (16.3) will fix this issue, that hasn't
> shipped yet. Until then Clang wouldn't work with MSVC's headers which seems
> unfortunate. Let's keep this in until VS 16.3 ships. (See also PR42843.)
>
>> Fixes link errors with clang and the latest Visual C++ 14.21.27702
>> headers, which was reported as PR42027.
>>
>> I chose to intentionally make these things linkonce_odr, i.e.
>> discardable, so that we don't emit definitions of these things in every
>> translation unit that includes STL headers.
>>
>> Note that this is *not* what MSVC does: MSVC has not yet implemented C++
>> DR2387, so they emit fully specialized constexpr variable templates with
>> static / internal linkage.
>>
>> Reviewers: rsmith
>>
>> Differential Revision: https://reviews.llvm.org/D63175
llvm-svn: 372844
|
|
|
|
|
|
|
|
| |
This fixes PR42407.
Differential Revision: https://reviews.llvm.org/D67053
llvm-svn: 372843
|
|
|
|
| |
llvm-svn: 372842
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clangdServer.
Summary: This is a NFC change.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67960
llvm-svn: 372841
|
|
|
|
| |
llvm-svn: 372840
|
|
|
|
|
|
|
|
|
|
|
| |
During legalisation we can end up with some pretty strange nodes, like shifts
of 0. We need to make sure we don't try to make long shifts of these, ending up
with invalid assembly instructions. A long shift with a zero immediate actually
encodes a shift by 32.
Differential Revision: https://reviews.llvm.org/D67664
llvm-svn: 372839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
relocation resolver.
The crash might happen when we have either a broken or unsupported object
and trying to resolve relocations when dumping the .stack_sizes section.
For the test case I used a 32-bits ELF header and a 64-bit relocation.
In this case a null pointer is returned by the code instead of the relocation
resolver function and then we crash.
Differential revision: https://reviews.llvm.org/D67962
llvm-svn: 372838
|
|
|
|
| |
llvm-svn: 372837
|
|
|
|
|
|
| |
Those two classes were mostly copy-pasted.
llvm-svn: 372836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix installing Python modules on systems that use /usr/lib for Python
while installing other libraries in /usr/lib64. Rewrite CMake logic
to query correct directories from Python, similarly to how
prepare_binding_Python.py does it. Furthermore, change the regex used
in get_relative_lib_dir.py to allow 'lib' without suffix.
I think that the code can be further improved but I'd like to take
this enterprise in smaller steps in case one of them breaks something.
Differential Revision: https://reviews.llvm.org/D67890
llvm-svn: 372835
|
|
|
|
|
|
|
|
|
| |
Read[Buffer/String]AndDumpToStreamOptions
All this code isn't used anywhere and method chaining isn't really useful for some
option struct.
llvm-svn: 372834
|
|
|
|
|
|
|
|
|
|
| |
Add the image query builtin functions from the OpenCL C specification.
Patch by Pierre Gondois and Sven van Haastregt.
Differential Revision: https://reviews.llvm.org/D67713
llvm-svn: 372833
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also reverts:
- r372778: [libc++] Implement LWG 3158
- r372782: [libc++] Try fixing tests that fail on GCC 5 and older
- r372787: Purge mentions of GCC 4 from the test suite
Reason: the change breaks compilation of LLVM with libc++, for details see
http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html
llvm-svn: 372832
|
|
|
|
| |
llvm-svn: 372830
|
|
|
|
|
|
|
| |
This matches GenericScheduler::pickNodeFromQueue, from which this
function was mostly cut and pasted.
llvm-svn: 372829
|
|
|
|
|
|
|
| |
This overload was left over from an operator new that was removed in
r123027. Fix it to match another operator new that was added in r248453.
llvm-svn: 372828
|
|
|
|
|
|
|
|
| |
That flag was introduced in Clang 6.0, so this made the test fail
with Clang <= 5.0. As it only influences linking builtin libraries
like -m which aren't relevant for this test, we can drop this flag.
llvm-svn: 372827
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66937
llvm-svn: 372825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think we should be able to use shl instead of sshl and ushl for
positive constant shift values, unless I am missing something.
We already have the machinery in place to ensure we only replace
nodes, if the shift value is positive and <= the element width.
This is a generalization of an earlier patch rL372565.
Reviewers: t.p.northover, samparker, dmgreen, anemet
Reviewed By: anemet
Differential Revision: https://reviews.llvm.org/D67955
llvm-svn: 372824
|
|
|
|
|
|
|
|
| |
In top level expressions, we don't have a m_source_code and we don't need to change
the source bounds (as no wrapping happend there). Fixes the test on the
sanitizer bot.
llvm-svn: 372817
|
|
|
|
|
|
| |
Using asserts doesn't print a useful error message in case this test fails.
llvm-svn: 372815
|
|
|
|
|
|
|
|
|
|
| |
The option was added to lld in D67481/372807.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D68009
llvm-svn: 372814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Similar to std::unordered_map::insert_or_assign
Reviewers: alexshap, bkramer, dblaikie, lhames
Subscribers: jkorous, dexonsmith, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67668
llvm-svn: 372813
|
|
|
|
|
|
| |
s16.
llvm-svn: 372812
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Object/MachOObjectFile.cpp:2731:7: warning: suggest braces around initialization of subobject [-Wmissing-braces]
"i386", "x86_64", "x86_64h", "armv4t", "arm", "armv5e",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{
1 warning generated.
/local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp:355:46: warning: suggest braces around initialization of subobject [-Wmissing-braces]
return addMappingFromTable<1>(MI, MRI, { 0 }, Table);
^
{}
1 warning generated.
/local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/tools/llvm-objcopy/ELF/Object.cpp:400:57: warning: suggest braces around initialization of subobject [-Wmissing-braces]
static constexpr std::array<uint8_t, 4> ZlibGnuMagic = {'Z', 'L', 'I', 'B'};
^~~~~~~~~~~~~~~~~~
{ }
1 warning generated.
llvm-svn: 372811
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-B is ignored for GNU objcopy compatibility after D67215/r371914.
* Delete mentions of -B from input-output-target.test - we have enough -B tests.
* Merge binary-input-with-arch.test into binary-output-target.test.
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D67693
llvm-svn: 372809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
noseparate-code
D64906 allows PT_LOAD to have overlapping p_offset ranges. In the
default R RX RW RW layout + -z noseparate-code case, we do not tail pad
segments when transiting to another segment. This can save at most
3*maxPageSize bytes.
a) Before D64906, we tail pad R, RX and the first RW.
b) With -z separate-code, we tail pad R and RX, but not the first RW (RELRO).
In some cases, b) saves one file page. In some cases, b) wastes one
virtual memory page. The waste is a concern on Fuchsia. Because it uses
compressed binaries, it doesn't benefit from the saved file page.
This patch adds -z separate-loadable-segments to restore the behavior before
D64906. It can affect section addresses and can thus be used as a
debugging mechanism (see PR43214 and ld.so partition bug in
crbug.com/998712).
Reviewed By: jakehehrlich, ruiu
Differential Revision: https://reviews.llvm.org/D67481
llvm-svn: 372807
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D67431
llvm-svn: 372803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_castf64_u64, _castu32_f32, _castu64_f64
Summary:
Adding support for some missing intrinsics:
_castf32_u32, _castf64_u64, _castu32_f32, _castu64_f64
Reviewers: craig.topper, LuoYuanke, RKSimon, pengfei
Reviewed By: RKSimon
Subscribers: llvm-commits
Patch by yubing (Bing Yu)
Differential Revision: https://reviews.llvm.org/D67212
llvm-svn: 372802
|