* Remove LLVM_ENABLE_CRT_REPORT. LLVM_DISABLE_CRASH_REPORT made it redundant.
* set Return to 1, so that we get a stack trace on failure.
* don't call _exit, so that we get a negative exit value and "not --crash"
correctly differentiates crashes and regular errors.
This is a bit experimental since the documentation on this interface is sparse.
It doesn't bring up a dialog on my windows setup, but feel free to revert
if it causes problem for your setup (and let me know what it is so that I
can try to fix this patch).
llvm-svn: 187206
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.
llvm-svn: 187179
Before this patch we would strdup each argument. If one was a response file,
we would replace it with the response file contents, leaking the original
strdup result.
We now don't strdup the originals and let StringSaver free any memory it
allocated. This also saves a bit of malloc traffic when response files are
not used.
Leak found by the valgrind build bot.
llvm-svn: 187042
The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.
There are other cleanups that should be done in this area:
* A client should not have to pass the size (even an explicit -1) to say if
it wants a null terminator or not, so we should probably swap the argument
order.
* The default should be to not require a null terminator. Very few clients
require this, but many end up asking for it just because it is the default.
llvm-svn: 186984
* assert that the return value is one of the documented values on msdn.
* on FILE_TYPE_UNKNOWN, check GetLastError.
Unfortunately I can't think of a way to get a FILE_TYPE_UNKNOWN on a test.
llvm-svn: 186595
The plan is to use it for clang and lld.
Major behavior changes:
- We can now parse UTF-16 files that have a byte order mark.
- PR16209: Don't drop backslashes on the floor if they don't escape
anything.
The actual parsing loop was based on code from Clang's driver.cpp,
although it's been rewritten to track its state with control flow rather
than state variables.
Reviewers: hans
Differential Revision: http://llvm-reviews.chandlerc.com/D1170
llvm-svn: 186587
There were a couple of different loops that were not handling
'.' correctly in APFloat::convertFromHexadecimalString; these mistakes
could lead to assertion failures and incorrect rounding for overlong
hex float literals.
Fixes PR16643.
llvm-svn: 186539
This should fix the windows bots. It looks like the failing tests are of the
form
prog1 > file
prog2 file
and prog2 fails trying to read the file. The best fix would probably be to close
stdout/stderr in prog1, but it was not the intention of 186511 to change this,
so just restore the old behavior for now.
llvm-svn: 186530
This has some advantages:
* Lets us use native, utf16 windows functions.
* Easy to produce good errors on windows about trying to use a
directory when we want a file.
* Simplifies the unix version a bit.
llvm-svn: 186511
Rename's documentation says "Files are renamed as if by POSIX rename()". and it
is used for atomically updating output files from a temporary. Having rename
fallback to a non atomic copy has the potential to hide bugs, like using
a temporary file in /tmp instead of a unique name next to the final destination.
llvm-svn: 186483
This is to support parsing UTF16 response files in LLVM/lib/Option for
lld and clang.
Reviewers: hans
Differential Revision: http://llvm-reviews.chandlerc.com/D1138
llvm-svn: 186426
When truncating to a format with fewer mantissa bits, APFloat::convert
will perform a right shift of the mantissa by the difference of the
precision of the two formats. Usually, this will result in just the
mantissa bits needed for the target format.
One special situation is if the input number is denormal. In this case,
the right shift may discard significant bits. This is usually not a
problem, since truncating a denormal usually results in zero (underflow)
after normalization anyway, since the result format's exponent range is
usually smaller than the target format's.
However, there is one case where the latter property does not hold:
when truncating from ppc_fp128 to double. In particular, truncating
a ppc_fp128 whose first double of the pair is denormal should result
in just that first double, not zero. The current code however
performs an excessive right shift, resulting in lost result bits.
This is then caught in the APFloat::normalize call performed by
APFloat::convert and causes an assertion failure.
This patch checks for the scenario of truncating a denormal, and
attempts to (possibly partially) replace the initial mantissa
right shift by decrementing the exponent, if doing so will still
result in a valid *target format* exponent.
Index: test/CodeGen/PowerPC/pr16573.ll
===================================================================
--- test/CodeGen/PowerPC/pr16573.ll (revision 0)
+++ test/CodeGen/PowerPC/pr16573.ll (revision 0)
@@ -0,0 +1,11 @@
+; RUN: llc < %s | FileCheck %s
+
+target triple = "powerpc64-unknown-linux-gnu"
+
+define double @test() {
+ %1 = fptrunc ppc_fp128 0xM818F2887B9295809800000000032D000 to double
+ ret double %1
+}
+
+; CHECK: .quad -9111018957755033591
+
Index: lib/Support/APFloat.cpp
===================================================================
--- lib/Support/APFloat.cpp (revision 185817)
+++ lib/Support/APFloat.cpp (working copy)
@@ -1956,6 +1956,23 @@
X86SpecialNan = true;
}
+ // If this is a truncation of a denormal number, and the target semantics
+ // has larger exponent range than the source semantics (this can happen
+ // when truncating from PowerPC double-double to double format), the
+ // right shift could lose result mantissa bits. Adjust exponent instead
+ // of performing excessive shift.
+ if (shift < 0 && isFiniteNonZero()) {
+ int exponentChange = significandMSB() + 1 - fromSemantics.precision;
+ if (exponent + exponentChange < toSemantics.minExponent)
+ exponentChange = toSemantics.minExponent - exponent;
+ if (exponentChange < shift)
+ exponentChange = shift;
+ if (exponentChange < 0) {
+ shift -= exponentChange;
+ exponent += exponentChange;
+ }
+ }
+
// If this is a truncation, perform the shift before we narrow the storage.
if (shift < 0 && (isFiniteNonZero() || category==fcNaN))
lostFraction = shiftRight(significandParts(), oldPartCount, -shift);
llvm-svn: 186409
The status function is already using a syscall that returns the file size.
Remember it and implement file_size as a simple wrapper.
No functionally change, but clients that already use status now can avoid
calling file_size.
llvm-svn: 186016
Remove the implementation in include/llvm/Support/YAMLTraits.h.
Added a DenseMap type DITypeHashMap in DebugInfo.h:
DenseMap<std::pair<StringRef, unsigned>, MDNode*>
llvm-svn: 185852
This function is complementary to createTemporaryFile. It handles the case were
the unique file is *not* temporary: we will rename it in the end. Since we
will rename it, the file has to be in the same filesystem as the final
destination and we don't prepend the system temporary directory.
This has a small semantic difference from unique_file: the default mode is 0666.
This matches the behavior of most unix tools. For example, with this change
lld now produces files with the same permissions as ld. I will add a test
of this change when I port clang over to createUniqueFile (next commit).
llvm-svn: 185726
This function is inspired by clang's Driver::GetTemporaryPath. It hides the
pattern used for uniquing and requires simple file names that are always
placed in the system temporary directory.
llvm-svn: 185716
Allow a BlockFrequency to be divided by a non-zero BranchProbability
with saturating arithmetic. This will be used to compute the frequency
of a loop header given the probability of leaving the loop.
Our long division algorithm already saturates on overflow, so that was a
freebie.
llvm-svn: 185184
* Don't try to create parent directories in unique_file. It had two problem:
* It violates the contract that it is atomic. If the directory creation
success and the file creation fails, we would return an error but the
file system was modified.
* When creating a temporary file clang would have to first check if the
parent directory existed or not to avoid creating one when it was not
supposed to.
* More efficient implementations of createUniqueDirectory and the unique_file
that produces only the file name. Now all 3 just call into a static
function passing what they want (name, file or directory).
Clang also has to be updated, so tests might fail if a bot picks up this commit
and not the corresponding clang one.
llvm-svn: 185126
This reverts commit r185099.
Looks like both the ppc-64 and mips bots are still failing after I reverted this
change.
Since:
1. The mips bot always performs a clean build,
2. The ppc64-bot failed again after a clean build (I asked the ppc-64
maintainers to clean the bot which they did... Thanks Will!),
I think it is safe to assume that this change was not the cause of the failures
that said builders were seeing. Thus I am recomitting.
llvm-svn: 185111
This reverts commit r185095. This is causing a FileCheck failure on
the 3dnow intrinsics on at least the mips/ppc bots but not on the x86
bots.
Reverting while I figure out what is going on.
llvm-svn: 185099
The category which an APFloat belongs to should be dependent on the
actual value that the APFloat has, not be arbitrarily passed in by the
user. This will prevent inconsistency bugs where the category and the
actual value in APFloat differ.
I also fixed up all of the references to this constructor (which were
only in LLVM).
llvm-svn: 185095
There are a few valid situation where we care about the structure inside a
directory, but not about the directory itself. A simple example is for unit
testing directory traversal.
PathV1 had a function like this, add one to V2 and port existing users of the
created temp file and delete it hack to using it.
llvm-svn: 185059
Currently inside APFloat fcNormal still implies the old definition of Normal
(i.e. isFiniteNonZero) instead of the proper IEEE-754R definition that the
external method isNormal() uses.
This patch prepares for the internal switch inside APFloat by converting all
references that check if a category is fcNormal directly with an indirect call
via isFiniteNonZero().
llvm-svn: 185036
This is easier to read than the internal fixed-point representation.
If anybody knows the correct algorithm for converting fixed-point
numbers to base 10, feel free to fix it.
llvm-svn: 184881
This is really ugly, but it is no worse than what we have in clang right now and
it is better to get it working first and clean/optimize it afterwards.
Will be tested from clang in the next patch.
llvm-svn: 184802
The method significandParts() is a helper method meant to ease access to
APFloat's significand by allowing the user to not need to be aware of whether or
not the APFloat is using memory allocated in the instance itself or in an
external array.
This assert says that one can only access the significand of FiniteNonZero/NaN
floats. This makes it cumbersome and more importantly dangerous when one wishes
to zero out the significand of a zero/infinity value since one will have to deal
with the aforementioned quandary related to how the memory in APFloat is
allocated.
llvm-svn: 184711
In the context of APFloat, seeing a macro called convolve suggests that APFloat
is using said value in some sort of convolution somewhere in the source code.
This is misleading.
I also added a documentation comment to the macro.
llvm-svn: 184710
exponent_t is only used internally in APFloat and no exponent_t values are
exposed via the APFloat API. In light of such conditions it does not make any
sense to gum up the llvm namespace with said type. Plus it makes it clearer that
exponent_t is associated with APFloat.
llvm-svn: 184686
Zero is used by BlockFrequencyInfo as a special "don't know" value. It also
causes a sink for frequencies as you can't ever get off a zero frequency with
more multiplies.
This recovers a 10% regression on MultiSource/Benchmarks/7zip. A zero frequency
was propagated into an inner loop causing excessive spilling.
PR16402.
llvm-svn: 184584
in the "parent" thread, when we are using CrashRecoveryContext::RunSafelyOnThread.
When using CrashRecoveryContext::RunSafelyOnThread, we would set a CrashRecoveryContextImpl* to a thread-local variable
for the "child" thread, but CrashRecoveryContext would erroneously clear it in the "parent" thread.
The result was that if CrashRecoveryContext::RunSafelyOnThread was called again in the "child" thread it would mess up
crash-recovery for its parent.
A test for this will be added in the clang repository.
rdar://14204560
llvm-svn: 184380
Rafael Espindola