| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mark destination buffer in zlib::compress and zlib::decompress as fully
initialized.
When building LLVM with system zlib and MemorySanitizer instrumentation,
MSan does not observe memory writes in zlib code and erroneously considers
zlib output buffers as uninitialized, resulting in false use-of-uninitialized
memory reports. This change helps MSan understand the state of that memory
and prevents such reports.
llvm-svn: 222763
|
|
|
|
|
|
|
| |
Allows long paths for the executable and redirected stdin/stdout/stderr.
Addresses PR21563.
llvm-svn: 222671
|
|
|
|
|
|
| |
Debug output is shown if any of the -debug-only arguments match.
llvm-svn: 222547
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"global-init", "global-init-src" and "global-init-type" were originally
used to blacklist entities in ASan init-order checker. However, they
were never documented, and later were replaced by "=init" category.
Old blacklist entries should be converted as follows:
* global-init:foo -> global:foo=init
* global-init-src:bar -> src:bar=init
* global-init-type:baz -> type:baz=init
llvm-svn: 222401
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As detailed at http://llvm.org/PR20728, due to an internal overflow in
APFloat::multiplySignificand the APFloat::fusedMultiplyAdd method can return
incorrect results for x87DoubleExtended (x86_fp80) values. This commonly
manifests as incorrect constant folding of libm fmal calls on x86. E.g.
fmal(1.0L, 1.0L, 3.0L) == 0.0L (should be 4.0L)
This patch fixes PR20728 by adding an extra bit to the significand for
intermediate results of APFloat::multiplySignificand, avoiding the overflow.
llvm-svn: 222374
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pair<iterator, bool>
This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.
This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...
llvm-svn: 222334
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
|
|
|
|
| |
llvm-svn: 222208
|
|
|
|
|
|
|
|
|
| |
The triple parser should only accept existing architecture names
when the triple starts with armv, armebv, thumbv or thumbebv.
Patch by Gabor Ballabas.
llvm-svn: 222129
|
|
|
|
|
|
|
| |
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
if (ec = widenPath(path, path_utf16))
llvm-svn: 222122
|
|
|
|
|
|
| |
on msc17. *These were added in VS 2013*
llvm-svn: 221971
|
|
|
|
|
|
| |
VS 2012 doesn't have fminf or fmaxf.
llvm-svn: 221949
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for LLI failure on Windows\X86: http://llvm.org/PR5053
LLI.exe crashes on Windows\X86 when single precession floating point
intrinsics like the following are used: acos, asin, atan, atan2, ceil,
copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh,
sqrt, tan, tanh
The above intrinsics are defined as inline-expansions in math.h, and are
not exported by msvcr120.dll (Win32 API GetProcAddress returns null).
For an FREM instruction, the JIT compiler generates a call to a stub for
the fmodf() intrinsic, and adds a relocation to fixup at load time. The
loader searches the libraries for the function, but fails because the
symbol is not exported. So, the call target remains NULL and the
execution crashes.
Since the math functions are loaded at JIT/runtime, the JIT can patch
CALL instruction directly instead of the searching the libraries'
exported symbols. However, this fix caused build failures due to
unresolved symbols like _fmodf at link time.
Therefore, the current fix defines helper functions in the Runtime
link/load library to perform the above operations. The address of these
helper functions are used to patch up the CALL instruction at load time.
Reviewers: lhames, rnk
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D5387
Patch by Swaroop Sridhar!
llvm-svn: 221947
|
|
|
|
|
|
| |
Fixes the MSVC "14" build.
llvm-svn: 221932
|
|
|
|
|
|
| |
evaluate to true). Also fixing a -Wcast-qual warning, where the cast expression isn't required.
llvm-svn: 221888
|
|
|
|
|
|
|
| |
The reading of 64 bit values could still be optimized, but at least this cuts
down on the number of virtual calls to fetch more data.
llvm-svn: 221865
|
|
|
|
|
|
|
|
|
|
| |
Windows normally limits the length of an absolute path name to 260
characters; directories can have lower limits. These limits increase
to about 32K if you use absolute paths with the special '\\?\'
prefix. Teach Support\Windows\Path.inc to use that prefix as needed.
TODO: Other parts of Support could also learn to use this prefix.
llvm-svn: 221841
|
|
|
|
|
|
|
| |
This allows the removal of isObjectEnd and opens the way for reading 64 bits
at a time.
llvm-svn: 221804
|
|
|
|
|
|
|
| |
Returning more information will allow BitstreamReader to be simplified a bit
and changed to read 64 bits at a time.
llvm-svn: 221794
|
|
|
|
|
|
|
|
|
| |
Every MemoryObject is a StreamableMemoryObject since the removal of
StringRefMemoryObject, so just merge the two.
I will clean up the MemoryObject interface in the upcoming commits.
llvm-svn: 221766
|
|
|
|
| |
llvm-svn: 221759
|
|
|
|
| |
llvm-svn: 221758
|
|
|
|
| |
llvm-svn: 221757
|
|
|
|
| |
llvm-svn: 221755
|
|
|
|
| |
llvm-svn: 221547
|
|
|
|
|
|
|
|
| |
built as SHARED. Users of LLVMSupport won't inherit ${system_libs}.
unittests/SupporTests is another user of libpthreads. Apply LLVM_SYSTEM_LIBS for him explicitly.
llvm-svn: 221531
|
|
|
|
| |
llvm-svn: 221422
|
|
|
|
| |
llvm-svn: 221333
|
|
|
|
|
|
|
|
|
| |
Commit 220932 caused crash when building clang-tblgen on aarch64 debian target,
so it's blocking all daily tests.
The std::call_once implementation in pthread has bug for aarch64 debian.
llvm-svn: 221331
|
|
|
|
| |
llvm-svn: 221258
|
|
|
|
|
|
| |
signed/unsigned mismatch.
llvm-svn: 221252
|
|
|
|
|
|
|
|
|
| |
SearchPath() to appease clang Driver's tests.
It seems SearchPath() doesn't show actual extension on the filesystem.
FIXME: Shall we use FindFirstFile() here?
llvm-svn: 221246
|
|
|
|
|
|
|
|
|
|
|
|
| |
1>C:\Program Files (x86)\Windows Kits\8.1\Include\um\minwinbase.h(46):
error C2146: syntax error : missing ';' before identifier 'nLength'
1>C:\Program Files (x86)\Windows Kits\8.1\Include\um\minwinbase.h(46):
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
...
including <windows.h> is actually required.
llvm-svn: 221244
|
|
|
|
| |
llvm-svn: 221221
|
|
|
|
| |
llvm-svn: 221220
|
|
|
|
|
|
|
| |
The MRI scripts have to work with CRLF, and in general it is probably
a good idea to support this in a core utility like LineIterator.
llvm-svn: 221153
|
|
|
|
|
|
|
| |
This is required by the interpreter library, and also matches the autoconf
behavior.
llvm-svn: 221147
|
|
|
|
|
|
|
|
|
|
| |
Tested this by #if 0'ing out the pthreads implementation, which
indicated that this fallback was not currently compiling successfully
and applying this patch resolves that.
Patch by Andy Chien.
llvm-svn: 220969
|
|
|
|
| |
llvm-svn: 220936
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to initialize the ManagedStatic mutex.
Summary:
This patch adds an llvm_call_once which is a wrapper around std::call_once on platforms where it is available and devoid of bugs. The patch also migrates the ManagedStatic mutex to be allocated using llvm_call_once.
These changes are philosophically equivalent to the changes added in r219638, which were reverted due to a hang on Win32 which was the result of a bug in the Windows implementation of std::call_once.
Reviewers: aaron.ballman, chapuni, chandlerc, rnk
Reviewed By: rnk
Subscribers: majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D5922
llvm-svn: 220932
|
|
|
|
|
|
|
|
| |
Setting ChildPid to -1 would cause waitpid to wait for any child process.
Patch by Daniel Reynaud!
llvm-svn: 220717
|
|
|
|
|
|
|
|
|
|
| |
In post-commit review of r219442, Rafael pointed out that the comment style
of the newly introduced helper didn't follow LLVM's coding standard.
Modernize the whole file to the new standards.
Differential Revision: http://reviews.llvm.org/D5918
llvm-svn: 220467
|
|
|
|
| |
llvm-svn: 220412
|
|
|
|
| |
llvm-svn: 220251
|
|
|
|
| |
llvm-svn: 219975
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cl::opts.
Summary:
This is based on the discussions from the LLVMDev thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075886.html
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5389
llvm-svn: 219854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reapply r216913, a fix for PR20832 by Andrea Di Biagio. The commit was reverted
because of buildbot failures, and credit goes to Ulrich Weigand for isolating
the underlying issue (which can be confirmed by Valgrind, which does helpfully
light up like the fourth of July). Uli explained the problem with the original
patch as:
It seems the problem is calling multiplySignificand with an addend of category
fcZero; that is not expected by this routine. Note that for fcZero, the
significand parts are simply uninitialized, but the code in (or rather, called
from) multiplySignificand will unconditionally access them -- in effect using
uninitialized contents.
This version avoids using a category == fcZero addend within
multiplySignificand, which avoids this problem (the Valgrind output is also now
clean).
Original commit message:
[APFloat] Fixed a bug in method 'fusedMultiplyAdd'.
When folding a fused multiply-add builtin call, make sure that we propagate the
correct result in the case where the addend is zero, and the two other operands
are finite non-zero.
Example:
define double @test() {
%1 = call double @llvm.fma.f64(double 7.0, double 8.0, double 0.0)
ret double %1
}
Before this patch, the instruction simplifier wrongly folded the builtin call
in function @test to constant 'double 7.0'.
With this patch, method 'fusedMultiplyAdd' correctly evaluates the multiply and
propagates the expected result (i.e. 56.0).
Added test fold-builtin-fma.ll with the reproducible from PR20832 plus extra
test cases to verify the behavior of method 'fusedMultiplyAdd' in the presence
of NaN/Inf operands.
This fixes PR20832.
llvm-svn: 219708
|
|
|
|
|
|
|
|
| |
ManagedStatic.cpp by controlling the allocation and de-allocation of the mutex."
It caused hang-up on msc17 builder, probably deadlock.
llvm-svn: 219687
|
|
|
|
|
|
|
|
| |
allocation and de-allocation of the mutex.
This patch adds a new llvm_call_once function which is used by the ManagedStatic implementation to safely initialize a global to avoid static construction and destruction.
llvm-svn: 219638
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a transform that changes:
(x lshr C1) udiv C2
into:
x udiv (C2 << C1)
However, it is unsafe to do so if C2 << C1 discards any of C2's bits.
This fixes PR21255.
llvm-svn: 219634
|