On Windows when raw_fd_ostream::write_impl calls write, a 32 bit input
is required for character count. As a variable with size_t is used for
this argument on x64 integral demotion occurs. In the case of large
files an infinite loop follows.
See PR37926.
This fix allows the output of files larger than previous int32 limit.
Differential Revision: https://reviews.llvm.org/D48948
Patch by Owen Reynolds
Reviewed by: zturner
llvm-svn: 338027
The AsmPrinter created in the tests contained an uninitialized
TargetLoweringObjectFile. Things mostly worked regardless, because we
used a separate instance of that class to specify sections to emit.
This rearanges the object construction order so that we can avoid
creating two lowering objects. Instead, we properly initialize the
object in the AsmPrinter, and have the DWARF generator store a pointer
to it.
llvm-svn: 338026
Summary:
This patch replaces the current method of getting an `APSInt` from Z3's model by calling generic API method `getBitvector` instead of `Z3_get_numeral_uint64`.
By calling `getBitvector`, there's no need to handle bitvectors with bit width == 128 separately.
And, as a bonus, clang now compiles correctly with Z3 4.7.1.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D49818
llvm-svn: 338020
Override getTypeForExtReturn so that functions returning
an i32 typed value have it sign extended on MIPS64.
Also provide patterns to get rid of unneeded sign extensions
for arithmetic instructions which implicitly sign extend
their results.
Differential Revision: https://reviews.llvm.org/D48374
llvm-svn: 338019
This reverts commit r337951.
While that kind of shared constant generally works fine in a MinGW
setting, it broke some cases of inline assembly that worked before:
$ cat const-asm.c
int MULH(int a, int b) {
int rt, dummy;
__asm__ (
"imull %3"
:"=d"(rt), "=a"(dummy)
:"a"(a), "rm"(b)
);
return rt;
}
int func(int a) {
return MULH(a, 1);
}
$ clang -target x86_64-win32-gnu -c const-asm.c -O2
const-asm.c:4:9: error: invalid variant '00000001'
"imull %3"
^
<inline asm>:1:15: note: instantiated into assembly here
imull __real@00000001(%rip)
^
A similar error is produced for i686 as well. The same test with a
target of x86_64-win32-msvc or i686-win32-msvc works fine.
llvm-svn: 338018
This patch introduces three essential types of query iterators:
`DocumentIterator`, `AndIterator`, `OrIterator`. It provides a
convenient API for query tree generation and serves as a building block
for the next generation symbol index - Dex. Currently, many
optimizations are missed to improve code readability and to serve as the
reference implementation. Potential improvements are briefly mentioned
in `FIXME`s and will be addressed in the following patches.
Dex RFC in the mailing list:
http://lists.llvm.org/pipermail/clangd-dev/2018-July/000022.html
Iterators, their applications and potential extensions are explained in
detail in the design proposal:
https://docs.google.com/document/d/1C-A6PGT6TynyaX4PXyExNMiGmJ2jL1UwV91Kyx11gOI/edit#heading=h.903u1zon9nkj
Reviewers: ioeric, sammccall, ilya-biryukov
Subscribers: cfe-commits, klimek, jfb, mgrang, mgorny, MaskRay, jkorous,
arphaman
Differential Revision: https://reviews.llvm.org/D49546
llvm-svn: 338017
a helper function with a nice overview comment. NFC.
This is a preperatory refactoring to implementing another component of
mitigation here that was descibed in the design document but hadn't been
implemented yet.
llvm-svn: 338016
`global-symbol-builder` help message mentions `-executor=<string>`
option, but doesn't give any example of what the value could be
Assuming the most popular use case to be building the whole project
index, help message should probably give an example of such usage.
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49785
llvm-svn: 338015
Update the dSYM bundle in place when swapping out the accelerator
tables. This should unbreak the windows bot that have been failing with
an access denied.
llvm-svn: 338014
Summary:
The GCOV API can be used to parse gcda/gcno files, but in order to implement custom output formats, users need to reimplement everything.
If the FileInfo members were protected instead of private, they'd be able to reuse the code.
Reviewers: bogner, davide, scott.smith
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41802
llvm-svn: 338013
Summary:
If the contents are the same, the update most likely comes from the
fact that compile commands were invalidated. In that case we want to
avoid rebuilds in case the compile commands are actually the same.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: simark, javed.absar, MaskRay, jkorous, arphaman, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D49783
llvm-svn: 338012
This adds MC support for the crypto instructions that were made optional
extensions in Armv8.2-A (AArch64 only).
Differential Revision: https://reviews.llvm.org/D49370
llvm-svn: 338010
--strip-trailing-cr is a diffutils option which is also available on
BSD-licensed diff introduced in FreeBSD 11.2, however, it has a bug
comparing files mixing \r and \r\n. Use -b (POSIX) instead.
llvm-svn: 338008
I'm not sure if this was trying to avoid optimizing the new nodes further or what. Or maybe to prevent a cycle if something tried to reform the multiply? But I don't think its a reliable way to do that. If the user of the expanded multiply is visited by the DAGCombiner after this conversion happens, the DAGCombiner will check its operands, see that they haven't been visited by the DAGCombiner before and it will then add the first node to the worklist. This process will repeat until all the new nodes are visited.
So this seems like an unreliable prevention at best. So this patch just returns the new nodes like any other combine. If this starts causing problems we can try to add target specific nodes or something to more directly prevent optimizations.
Now that we handle the combine normally, we can combine any negates the mul expansion creates into their users since those will be visited now.
llvm-svn: 338007
Since r337668, we support statically linking dependencies only to shared
or static library. However, that change hasn't updated the check whether
to generate a linker script. We shouldn't generate linker script only in
the case when we aren't statically linked ABI into the shared library.
Differential Revision: https://reviews.llvm.org/D49834
llvm-svn: 338006
These calls were making sure some newly created nodes were added to worklist, but the DAGCombiner has internal support for ensuring it has visited all nodes. Any time it visits a node it ensures the operands have been queued to be visited as well. This means if we only need to return the last new node. The DAGCombiner will take care of adding its inputs thus walking backwards through all the new nodes.
llvm-svn: 337996
The function in question is copy-pasted lots of times in DWARF-related classes.
Thus it will make sense to place its implementation into the Support library.
Reviewed by: lhames
Differential Revision: https://reviews.llvm.org/D49824
llvm-svn: 337995
Summary:
Using int128_t with UBSAN causes link errors unless compiler-rt is providing the runtime library.
Specifically ubsan generates calls to __muloti4 but libgcc doesn't provide a definition.
In order to avoid this, and allow users to continue using sanitized versions of libc++, this patch introduces a hack.
It adds a cribbed version of the compiler-rt builtin to the libc++ filesystem sources.
I don't think this approach will work in the long run, but it seems OK for now.
Also see:
https://bugs.llvm.org/show_bug.cgi?id=30643https://bugs.llvm.org/show_bug.cgi?id=16404
Reviewers: mclow.lists, ldionne, rsmith, jyknight, echristo
Reviewed By: echristo
Subscribers: dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D49828
llvm-svn: 337990
- Remove unnecessary anchor function
- Remove unnecessary override of getAnalysisUsage
- Use reference instead of pointers where things cannot be nullptr
- Use ArrayRef instead of std::vector where possible
llvm-svn: 337989
- Avoid duplication of regmask size calculation.
- Simplify allocateRegisterMask() call.
- Rename allocateRegisterMask() to allocateRegMask() to be consistent
with naming in MachineOperand.
llvm-svn: 337986
Summary:
rL337867 introduced two new cmake_dependent_option options:
- LIBCXXABI_INSTALL_STATIC_LIBRARY
- LIBCXXABI_INSTALL_SHARED_LIBRARY
They depend on LIBCXXABI_ENABLE_STATIC and LIBCXXABI_ENABLE_SHARED
and so therefore need to (it seems) come after the declaration of
these two options.
Subscribers: mgorny, aheejin, christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D49825
llvm-svn: 337982
This patch add support for emitting DWARF5 accelerator tables
(.debug_names) from dsymutil. Just as with the Apple style accelerator
tables, it's possible to update existing dSYMs. This patch includes a
test that show how you can convert back and forth between the two types.
If no kind of table is specified, dsymutil will default to generating
Apple-style accelerator tables whenever it finds those in its input. The
same is true when there are no accelerator tables at all. Finally, in
the remaining case, where there's at least one DWARF v5 table and no
Apple ones, the output will contains a DWARF accelerator tables
(.debug_names).
Differential revision: https://reviews.llvm.org/D49137
llvm-svn: 337980
This is a refinement on r337833. Previously we were installing two
copies of c++abi headers in libc++ build directory, one in
include/c++build and another one in include/c++/v1. However, the
second copy is unnecessary when building libc++ standalone.
Differential Revision: https://reviews.llvm.org/D49752
llvm-svn: 337979
Kirill Bobyrev