summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix off-by-one error in Regex::isValidAlexey Samsonov2013-08-081-1/+1
| | | | llvm-svn: 187992
* Changed isPrint for U+00AD SOFT HYPHEN to return true.Alexander Kornienko2013-08-081-183/+185
| | | | | | | | | | | | | | | | | Summary: This is consistent with MacOSX implementation, and most terminals actually display this character (checked on gnome-terminal, lxterminal, lxterm, Terminal.app, iterm2). Actually, this is in line with the ISO Latin 1 standard (ISO 8859-1), which defines it differently from the Unicode Standard. More information here: http://www.cs.tut.fi/~jkorpela/shy.html Reviewers: gribozavr, jordan_rose CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1310 llvm-svn: 187949
* On Windows, autolink advapi32 from Path.inc for CryptAcquireContextWReid Kleckner2013-08-071-0/+4
| | | | | | | | | | | This allows llvm-tblgen to link successfully when compiling with clang. Both MSBuild and CMake will automatically add advapi32 as part of a set of other dlls comprising the win32 API to the link line, but CMake doesn't do that when compiling with clang. Until someone adds that info to cmake upstream, this seems like a reasonable work around. llvm-svn: 187907
* Add support for linking against a curses library when available andChandler Carruth2013-08-071-10/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | using it to detect whether or not a terminal supports colors. This replaces a particularly egregious hack that merely compared the TERM environment variable to "dumb". That doesn't really translate to a reasonable experience for users that have actually ensured their terminal's capabilities are accurately reflected. This makes testing a terminal for color support somewhat more expensive, but it is called very rarely anyways. The important fast path when the output is being piped somewhere is already in place. The global lock may seem excessive, but the spec for calling into curses is *terrible*. The whole library is terrible, and I spent quite a bit of time looking for a better way of doing this before convincing myself that this was the fundamentally correct way to behave. The damage of the curses library is very narrowly confined, and we continue to use raw escape codes for actually manipulating the colors which is a much sane system than directly using curses here (IMO). If this causes trouble for folks, please let me know. I've tested it on Linux and will watch the bots carefully. I've also worked to account for the variances of curses interfaces that I could finde documentation for, but that may not have been sufficient. llvm-svn: 187874
* YAMLTraits.h: replace DenseMap that used a bad implementation of DenseMapInfoDmitri Gribenko2013-08-071-2/+2
| | | | | | | | | | for StringRef with a StringMap The bug is that the empty key compares equal to the tombstone key. Also added an assertion to DenseMap to catch similar bugs in future. llvm-svn: 187866
* Fix boolean logic in LockFileManager and test itReid Kleckner2013-08-071-8/+10
| | | | | | | | | | This fixes a bug from r187826. Reviewers: hans Differential Revision: http://llvm-reviews.chandlerc.com/D1304 llvm-svn: 187846
* Avoid using alloca in Windows/Program.incReid Kleckner2013-08-071-13/+15
| | | | | | | One use needs to copy the alloca into a std::string, and the other use is before calling CreateProcess, which is very heavyweight anyway. llvm-svn: 187845
* Implemented llvm::sys::locale::columnWidth and isPrint for the case of ↵Alexander Kornienko2013-08-071-5/+370
| | | | | | | | | | | | | | | | | | | | | generic UTF8-capable terminal. Summary: This is a second attempt to get this right. After reading the Unicode Standard I came up with the code that uses definitions of "printable" and "column width" more suitable for terminal output (i.e. fixed-width fonts and special treatment of many control characters). The implementation here can probably be used for Windows and MacOS if someone can test it properly. The patch addresses PR14910. Reviewers: jordan_rose, gribozavr CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1253 llvm-svn: 187837
* Remove some std stream usage from Support and TableGenReid Kleckner2013-08-062-14/+18
| | | | | | | | | | LLVM's coding standards recommend raw_ostream and MemoryBuffer for reading and writing text. This has the side effect of allowing clang to compile more of Support and TableGen in the Microsoft C++ ABI. llvm-svn: 187826
* Introduce Regex::isLiteralERE function.Peter Collingbourne2013-08-051-0/+7
| | | | | | | | | This will be used to implement an optimisation for literal entries in special case lists. Differential Revision: http://llvm-reviews.chandlerc.com/D1278 llvm-svn: 187731
* Fix windows' implementation of status when a file doesn't exist.Rafael Espindola2013-07-311-6/+11
| | | | | | | | | The unix one was returning no_such_file_or_directory, but the windows one was return success. Update the one one caller that was depending on the old behavior. llvm-svn: 187463
* Implement getUniqueID for directories on windows.Rafael Espindola2013-07-301-18/+14
| | | | llvm-svn: 187441
* Remove dead code.Rafael Espindola2013-07-301-3/+0
| | | | llvm-svn: 187439
* Implement TokenizeWindowsCommandLine.Rui Ueyama2013-07-301-1/+101
| | | | | | | | | | This is a follow up patch for r187390 to implement the parser for the Windows-style command line. This should follow the rule as described at http://msdn.microsoft.com/en-us/library/windows/desktop/17w5ykft(v=vs.85).aspx Differential Revision: http://llvm-reviews.chandlerc.com/D1235 llvm-svn: 187430
* Make file_status::getUniqueID const.Rafael Espindola2013-07-292-2/+2
| | | | llvm-svn: 187383
* Include st_dev to make the result of getUniqueID actually unique.Rafael Espindola2013-07-293-31/+21
| | | | | | This will let us use getUniqueID instead of st_dev directly on clang. llvm-svn: 187378
* Some Intel Penryn CPUs come with SSE4 disabled. Detect them as core 2.Benjamin Kramer2013-07-291-1/+3
| | | | | | PR16721. llvm-svn: 187350
* [APFloat] Make all arithmetic operations with NaN produce positive NaNs.Michael Gottesman2013-07-271-7/+10
| | | | | | | | | | | | | IEEE-754R 1.4 Exclusions states that IEEE-754R does not specify the interpretation of the sign of NaNs. In order to remove an irrelevant variable that most floating point implementations do not use, standardize add, sub, mul, div, mod so that operating anything with NaN always yields a positive NaN. In a later commit I am going to update the APIs for creating NaNs so that one can not even create a negative NaN. llvm-svn: 187314
* [APFloat] Move setting fcNormal in zeroSignificand() to calling code.Michael Gottesman2013-07-271-2/+4
| | | | | | | | Zeroing the significand of a floating point number does not necessarily cause a floating point number to become finite non zero. For instance, if one has a NaN, zeroing the significand will cause it to become +/- infinity. llvm-svn: 187313
* Revert "[PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc."Rafael Espindola2013-07-261-2/+2
| | | | | | This reverts commit r187248. It broke many bots. llvm-svn: 187254
* [PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc.Bill Schmidt2013-07-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Both GCC and LLVM will implicitly define __ppc__ and __powerpc__ for all PowerPC targets, whether 32- or 64-bit. They will both implicitly define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets, and not for 32-bit targets. We cannot be sure that all other possible compilers used to compile Clang/LLVM define both __ppc__ and __powerpc__, for example, so it is best to check for both when relying on either inside the Clang/LLVM code base. This patch makes sure we always check for both variants. In addition, it fixes one unnecessary check in lib/Target/PowerPC/PPCJITInfo.cpp. (At least one of __ppc__ and __powerpc__ should always be defined when compiling for a PowerPC target, no matter which compiler is used, so testing for them is unnecessary.) There are some places in the compiler that check for other variants, like __POWERPC__ and _POWER, and I have left those in place. There is no need to add them elsewhere. This seems to be in Apple-specific code, and I won't take a chance on breaking it. There is no intended change in behavior; thus, no test cases are added. llvm-svn: 187248
* Add missing 'n'.Rafael Espindola2013-07-261-1/+1
| | | | | | Thanks to Han Finkel for noticing it. llvm-svn: 187241
* Remove dead or useless header checks from cmake and autoconfReid Kleckner2013-07-263-18/+4
| | | | | | | | | | On Windows, this improves clean cmake configuration time on my workstation from 1m58s to 1m32s, which is pretty significant. There's probably more that can be done here, but this is the low hanging fruit. Eric volunteered to regenerate ./configure for me. llvm-svn: 187209
* Extend the lifetime of the strings passed to posix_spawn_file_actions_addopen.Rafael Espindola2013-07-261-7/+21
| | | | | | Thanks to Hal Finkel for finding the bug and for the initial patch. llvm-svn: 187208
* Improve our error handling on windows.Rafael Espindola2013-07-261-38/+1
| | | | | | | | | | | | | | * 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
* [PowerPC] Support powerpc64le as a syntax-checking target.Bill Schmidt2013-07-261-0/+8
| | | | | | | | | | | | | | | | | | | | | | | 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
* Remove the mblaze backend from llvm.Rafael Espindola2013-07-251-9/+0
| | | | | | Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html llvm-svn: 187145
* Don't end a file name with a dot. It looks odd.Rafael Espindola2013-07-251-1/+2
| | | | llvm-svn: 187124
* Don't leak when expanding response files.Rafael Espindola2013-07-241-17/+15
| | | | | | | | | | | | | | 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
* Split getOpenFile into getOpenFile and getOpenFileSlice.Rafael Espindola2013-07-231-7/+25
| | | | | | | | | | | | | | | | 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
* Fix size_t -> uint warnings with MSVC 64-bit buildMatt Arsenault2013-07-201-3/+3
| | | | llvm-svn: 186736
* Initialize TempFileHandle.Serge Pavlov2013-07-191-1/+1
| | | | llvm-svn: 186684
* Split openFileForWrite into windows and unix versions.Rafael Espindola2013-07-193-30/+79
| | | | | | It is similar to 186511, but for creating files for writing. llvm-svn: 186679
* Small improvement to the use of GetFileType:Rafael Espindola2013-07-181-1/+8
| | | | | | | | | * 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
* Windows/Path.inc: Introduce file_type::character_file and ↵NAKAMURA Takumi2013-07-181-0/+13
| | | | | | | | | file_type::fifo_file in sys::fs::getStatus(HANDLE). It fixes llvm/test/Other/close-stderr.ll on msys. FIXME: Provide unittests. llvm-svn: 186588
* [Support] Beef up and expose the response file parsing in llvm::clReid Kleckner2013-07-181-62/+141
| | | | | | | | | | | | | | | | | | | 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
* Remove dead code.Rafael Espindola2013-07-182-82/+0
| | | | llvm-svn: 186561
* Convert two uses if fstat with sys::fs::status.Rafael Espindola2013-07-181-14/+13
| | | | llvm-svn: 186560
* Handle '.' correctly in hex float literal parsing.Eli Friedman2013-07-171-30/+20
| | | | | | | | | | | 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
* Fix a funny typo. Thanks to Aaron Ballman for noticing.Rafael Espindola2013-07-171-1/+1
| | | | llvm-svn: 186532
* Add FILE_SHARE_WRITE to openFileForRead.Rafael Espindola2013-07-171-1/+1
| | | | | | | | | | | | | | 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
* Split openFileForRead into Windows and Unix versions.Rafael Espindola2013-07-173-15/+40
| | | | | | | | | | | 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
* Ensure sys::getProcessTriple always uses a normalized triple. Patch byDuncan Sands2013-07-171-1/+1
| | | | | | Thomas B. Jablin, from PR16636. llvm-svn: 186501
* Don't fallback to copy + delete in rename.Rafael Espindola2013-07-171-11/+2
| | | | | | | | | 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
* raw_ostream.cpp: Introduce <fcntl.h> to let O_BINARY provided. Or, ↵NAKAMURA Takumi2013-07-171-0/+5
| | | | | | | | llvm::outs() would be set to O_TEXT by default. llvm/test/Object/check_binary_output.ll is expected to pass on win32. llvm-svn: 186480
* Add a wrapper for open.Rafael Espindola2013-07-166-54/+66
| | | | | | | This centralizes the handling of O_BINARY and opens the way for hiding more differences (like how open behaves with directories). llvm-svn: 186447
* [Support] Add a Unicode conversion wrapper from UTF16 to UTF8Reid Kleckner2013-07-161-0/+55
| | | | | | | | | | | 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
* Create files with mode 666. This matches the behavior of other unix tools.Rafael Espindola2013-07-161-1/+1
| | | | llvm-svn: 186414
* [Support] Fix some warnings when self-hosting clang on WindowsReid Kleckner2013-07-162-2/+5
| | | | llvm-svn: 186413
* [APFloat] PR16573: Avoid losing mantissa bits in ppc_fp128 to double truncationUlrich Weigand2013-07-161-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud