subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Support/ThreadLocal.cpp:53:15: error: typedef 'SIZE_TOO_BIG' locally defined but not used [-Werror=unused-local-typedefs]
typedef int SIZE_TOO_BIG[sizeof(pthread_key_t) <= sizeof(data) ? 1 : -1];
Done the C++11 way, switching on and using LLVM_STATIC_ASSERT() instead of LLVM_ATTRIBUTE_UNUSED.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198255 91177308-0d34-0410-b5e6-96231b3b80d8
much more clear to me. I meant to make this change before committing the
original patch, but forgot to merge it in. Sorry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198069 91177308-0d34-0410-b5e6-96231b3b80d8
This is an iterator which you can build around a MemoryBuffer. It will
iterate through the non-empty, non-comment lines of the buffer as
a forward iterator. It should be small and reasonably fast (although it
could be made much faster if anyone cares, I don't really...).
This will be used to more simply support the text-based sample
profile file format, and is largely based on the original patch by
Diego. I've re-worked the style of it and separated it from the work of
producing a MemoryBuffer from a file which both simplifies the interface
and makes it easier to test.
The style of the API follows the C++ standard naming conventions to fit
in better with iterators in general, much like the Path and FileSystem
interfaces follow standard-based naming conventions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198068 91177308-0d34-0410-b5e6-96231b3b80d8
Recently, support for krait cpu was added. This commit extends getHostCPUName()
to return krait as cpu for the APQ8064 (a Krait 300).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197792 91177308-0d34-0410-b5e6-96231b3b80d8
According to the docs, ThreadLocal<>::get() should return NULL
if no object has been set. This patch makes that the case also for non-thread
builds and adds a very basic unit test to check it.
(This was causing PR18205 because PrettyStackTraceHead didn't get zero-
initialized and we'd crash trying to read past the end of that list. We didn't
notice this so much on Linux since we'd crash after printing all the entries,
but on Mac we print into a SmallString, and would crash before printing that.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197718 91177308-0d34-0410-b5e6-96231b3b80d8
DiagnosticPrinter.cpp.
These was creating a link time dependencies of IR on CodeGen and Analysis.
Part of <rdar://problem/15515174>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197447 91177308-0d34-0410-b5e6-96231b3b80d8
The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.
This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.
This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).
This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.
http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197438 91177308-0d34-0410-b5e6-96231b3b80d8
This was manifesting as an LLVM_ASSUME_ALIGNED() failure in an ELF debug
info test when building LLVM with clang in the Microsoft C++ ABI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197401 91177308-0d34-0410-b5e6-96231b3b80d8
The cpp backend is not a reasonable fallback for a missing target. It is a
very special backend, so it is reasonable to use it only if explicitly
requested.
While at it, simplify the interface a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197241 91177308-0d34-0410-b5e6-96231b3b80d8
The old AddFixedStringToRegEx() it was based on got away with this for the
longest time, but the problem became easy to spot after the cleanup in r197096.
Also add a quick unit test to cover regex escaping.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197121 91177308-0d34-0410-b5e6-96231b3b80d8
Both FileCheck and clang's -verify need to escape strings for regexes,
so let's expose this as a utility in the Regex class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197096 91177308-0d34-0410-b5e6-96231b3b80d8
Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful
option and can give surprising results (like tail calls being disabled).
5.0 seems like a reasonable compromise as a platform that's still interesting
to some people.
rdar://problem/15567348
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196912 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When clang is used under GNU/Linux in a chroot without /proc mount, it falls
back on the BSD method. However, since the buf variable is used twice
and fails with snprintf to produce the correct path.
When called as relatived (ie ./clang), it was failing with:
"" -cc1 [...] -x c++ x.cc
error: unable to execute command: Executable "" doesn't exist!
I also took the opportunity to simply the code (the first arg of test_dir
was useless).
Reviewers: rafael
Reviewed By: rafael
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2361
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196791 91177308-0d34-0410-b5e6-96231b3b80d8
Command line arguments that begin with @ but aren't a path to an
existing file currently cause later @file arguments to be ignored.
Correctly skip over these arguments instead of trying to read a
non-existent file 20 times and giving up.
Since the problem manifests in the clang driver, the test is in that
repository.
Fixes rdar://problem/15590906
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196620 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196471 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a logic bug pointed out by Juraj Ivancic.
No behavior change because none of the in-tree clients of
cl::ExpandResponseFiles check the return value. In this case, the
@prefixed arguments are left in the command line. Downstream command
line processing has the opportunity to emit errors about it, so this
isn't that bad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196306 91177308-0d34-0410-b5e6-96231b3b80d8
implementation. Silliness, but it'll be a trivial performance
optimization. This should clear up a failure on the vg_leak bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195704 91177308-0d34-0410-b5e6-96231b3b80d8
Enhance the tests to actually require moves in C++11 mode, in addition
to testing the moved-from state. Further enhance the tests to cover
copy-assignment into a moved-from object and moving a large-state
object. (Note that we can't really test small-state vs. large-state as
that isn't an observable property of the API really.) This should finish
addressing review on r195239.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195261 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow, this ADT got missed which is moderately terrifying considering
the efficiency of move for it.
The code to implement move semantics for it is pretty horrible
currently but was written to reasonably closely match the rest of the
code. Unittests that cover both copying and moving (at a basic level)
added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195239 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195064 91177308-0d34-0410-b5e6-96231b3b80d8
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194997 91177308-0d34-0410-b5e6-96231b3b80d8
This change is the first in a series of changes improving LLVM's Block
Frequency propogation implementation to not lose probability mass in
branchy code when propogating block frequency information from a basic
block to its successors. This patch is a simple infrastructure
improvement that does not actually modify the block frequency
algorithm. The specific changes are:
1. Changes the division algorithm used when scaling block frequencies by
branch probabilities to a short division algorithm. This gives us the
remainder for free as well as provides a nice speed boost. When I
benched the old routine and the new routine on a Sandy Bridge iMac with
disabled turbo mode performing 8192 iterations on an array of length
32768, I saw ~600% increase in speed in mean/median performance.
2. Exposes a scale method that returns a remainder. This is important so
we can ensure that when we scale a block frequency by some branch
probability BP = N/D, the remainder from the division by D can be
retrieved and propagated to other children to ensure no probability mass
is lost (more to come on this).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194950 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Some machine-type-neutral object files containing only undefined symbols
actually do exist in the Windows standard library. Need to recognize them
as COFF files.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2164
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194734 91177308-0d34-0410-b5e6-96231b3b80d8
stack traces by default if you use PrettyStackTraceProgram, so that existing LLVM-based
tools will continue to get it without any changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193971 91177308-0d34-0410-b5e6-96231b3b80d8
As on other hosts, the CPU identification instruction is priveleged,
so we need to look through /proc/cpuinfo. I copied the PowerPC way of
handling "generic".
Several tests were implicitly assuming z10 and so failed on z196.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193742 91177308-0d34-0410-b5e6-96231b3b80d8
This is a stopgap fix for cast warnings introduced in r192864.
A proper fix should be investigated by the author when possible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193160 91177308-0d34-0410-b5e6-96231b3b80d8
gcc diagnoses this:
warning: converting to non-pointer type 'unsigned int' from NULL
Also remove an empty statement.
No change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192955 91177308-0d34-0410-b5e6-96231b3b80d8
I expose the API with some caveats:
- The C++ API involves a traditional void* opaque pointer for the fatal
error callback. The C API doesn’t do this. I don’t think that the void*
opaque pointer makes any sense since this is a global callback - there will
only be one of them. So if you need to pass some data to your callback,
just put it in a global variable.
- The bindings will ignore the gen_crash_diag boolean. I ignore it because
(1) I don’t know what it does, (2) it’s not documented AFAIK, and (3) I
couldn’t imagine any use for it. I made the gut call that it probably
wasn’t important enough to expose through the C API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192864 91177308-0d34-0410-b5e6-96231b3b80d8
Some background: One can pass compiled resource files (.res files) directly
to the linker on Windows. If a resource file is given, the linker will run
"cvtres" command in background to convert the resource file to a COFF file
to link it.
What I'm trying to do with this patch is to make the linker to recognize
the resource file by file magic, so that it can run cvtres command.
Differential Revision: http://llvm-reviews.chandlerc.com/D1943
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192742 91177308-0d34-0410-b5e6-96231b3b80d8
We were using an anti-pattern of:
- LoadLibrary
- GetProcAddress
- FreeLibrary
This is problematic because of several reasons:
- We are holding on to pointers into a library we just unloaded.
- Calling LoadLibrary results in an increase in the reference count of
the library in question and any libraries that it depends on and
so-on and so-forth. This is none too quick.
Instead, use GetModuleHandleEx with GET_MODULE_HANDLE_EX_FLAG_PIN. This
is done because because we didn't bring the reference for the library
into existence and therefor shouldn't count on it being around later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192550 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Vladimir Voskresensky. The erros were:
Path.inc:274:3: error: ‘Dl_info’ was not declared in this scope
...
and
usr/include/spawn.h:52:14: error: expected ‘,’ or ‘...’ before ‘argv’
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192185 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses several issues in a similar vein:
- Use the Unicode APIs when possible, running nm on clang shows that we
only use Unicode APIs except for FormatMessage, CreateSemaphore, and
GetModuleHandle. AFAICT, the latter two are coming from MinGW and
not LLVM itself.
- Make getMainExecutable more resilient. It previously considered
return values of zero from ::GetModuleFileNameA to be acceptable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192096 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The MSVCRT deliberately sends main() code-page specific characters.
This isn't too useful to LLVM as we end up converting the arguments to
UTF-16 and subsequently attempt to use the result as, for example, a
file name. Instead, we need to have the ability to access the Unicode
command line and transform it to UTF-8.
This has the distinct advantage over using the MSVC-specific wmain()
function as our entry point because:
- It doesn't work on cygwin.
- It only work on MinGW with caveats and only then on certain versions.
- We get to keep our entry point as main(). :)
N.B. This patch includes fixes to other parts of lib/Support/Windows
s.t. we would be able to take advantage of getting the Unicode paths.
E.G. clang spawning clang -cc1 would want to give it Unicode arguments.
Reviewers: aaron.ballman, Bigcheese, rnk, ruiu
Reviewed By: rnk
CC: llvm-commits, ygao
Differential Revision: http://llvm-reviews.chandlerc.com/D1834
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192069 91177308-0d34-0410-b5e6-96231b3b80d8
- New ProcessInfo class to encapsulate information about child processes.
- Generalized the Wait() to support non-blocking wait on child processes.
- ExecuteNoWait() now returns a ProcessInfo object with information about
the launched child. Users will be able to use this object to
perform non-blocking wait.
- ExecuteNoWait() now accepts an ExecutionFailed param that tells if execution
failed or not.
These changes will allow users to implement basic process parallel
tools.
Differential Revision: http://llvm-reviews.chandlerc.com/D1728
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191763 91177308-0d34-0410-b5e6-96231b3b80d8
This makes using array_pod_sort significantly safer. The implementation relies
on function pointer casting but that should be safe as we're dealing with void*
here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191175 91177308-0d34-0410-b5e6-96231b3b80d8
This was previously invoking UB by passing a user-defined type to
format. Thanks to Jordan Rose for pointing this out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191060 91177308-0d34-0410-b5e6-96231b3b80d8
Based on code review feedback from Eric Christopher, unshifting these
constants as they can appear in the gdb_index itself, shifted a further
24 bits. This means that keeping them preshifted is a bit inflexible, so
let's not do that.
Given the motivation, wrap up some nicer enums, more type safety, and
some utility functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191035 91177308-0d34-0410-b5e6-96231b3b80d8
advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will
"reset" if you shutdown llvm and try to come back for seconds. This is a subtle
behavior change, but I'm assuming that nobody is affected by it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190946 91177308-0d34-0410-b5e6-96231b3b80d8
advertised - but it does have the caveat that calls to DynamicLibrary::AddSymbol will
"reset" if you shutdown llvm and try to come back for seconds. This is a subtle
behavior change, but I'm assuming that nobody is affected by it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190921 91177308-0d34-0410-b5e6-96231b3b80d8
This was somewhat tricky because ~PrettyStackTraceEntry() may run after
llvm_shutdown() has been called. This is rare and only happens for a common idiom
used in the main() functions of command-line tools. This works around the idiom by
skipping the stack clean-up if the PrettyStackTraceHead ManagedStatic is not
constructed (i.e. llvm_shutdown() has been called).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190730 91177308-0d34-0410-b5e6-96231b3b80d8
Implements Instruction scheduler latencies for Silvermont,
using latencies from the Intel Silvermont Optimization Guide.
Auto detects SLM.
Turns on post RA scheduler when generating code for SLM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190717 91177308-0d34-0410-b5e6-96231b3b80d8
global ThreadLocals, thereby getting rid of the load-time initialization of those
objects and also getting rid of their destruction unless the LLVM client calls
llvm_shutdown.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190617 91177308-0d34-0410-b5e6-96231b3b80d8
This reflects the common use case of nativizing a prepared path. The existing
version invokes undefined behavior if input = output, add an assert to catch
that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190510 91177308-0d34-0410-b5e6-96231b3b80d8
YAMLIO printed a string as is without quotes unless it contains a newline
character. That did not suffice. We also need to quote a string if it starts
with a backquote, quote, double quote or atsign, or it's the empty string.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190469 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases (e.g. when a build system pipes stderr) the Windows console
API cannot be used to color output. For these, provide a way to switch to
ANSI escape codes. This is required for Clang's -fansi-escape-codes option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190460 91177308-0d34-0410-b5e6-96231b3b80d8
On Windows, character encoding of multibyte environment variable varies
depending on settings. The only reliable way to handle it I think is to use
GetEnvironmentVariableW().
GetEnvironmentVariableW() works on wchar_t string, which is on Windows UTF16
string. That's not ideal because we use UTF-8 as the internal encoding in LLVM.
This patch defines a wrapper function which takes and returns UTF-8 string for
GetEnvironmentVariableW().
The wrapper function does not do any conversion and just forwards the argument
to getenv() on Unix.
Differential Revision: http://llvm-reviews.chandlerc.com/D1612
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190423 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is needed so we can use generic columnWidthUTF8 in clang-format on
win32 simultaneously with a separate system-dependent implementations of
isPrint/columnWidth in TextDiagnostic.cpp to avoid attempts to print Unicode
characters using narrow-character interfaces (which is not supported on Windows,
and we'll have to figure out how to handle this).
Reviewers: jordan_rose
Reviewed By: jordan_rose
CC: llvm-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189952 91177308-0d34-0410-b5e6-96231b3b80d8
For example, r189780's SparcISelLowering.cpp has the size 98304. It crashed clang to touch a null terminator on cygwin.
FIXME: It's not good to hardcode 4096 here. dwPageSize shows 4096.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189939 91177308-0d34-0410-b5e6-96231b3b80d8
printing routine. This is made harder to see due to the surprising
formatting, inconsistent brace usage, and repeated conditions that all
test the same thing.
The only "consequence" of this bug is re-assigning 'str' to an empty
string when computing the error string for an error number of 0 in the
event of a non-GNU strerror_r routine. So, nothing to see here other
than cleanup. It did help me find PR17055 in clang-format though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189734 91177308-0d34-0410-b5e6-96231b3b80d8
- We do some nasty things w.r.t. installing or overriding signal handlers in
order to improve our crash recovery support or interaction with crash
reporting software, and those things are not necessarily appropriate when
LLVM is being linked into a client application that has its own ideas about
how to do things. This gives those clients a way to disable that handling at
build time.
- Currently, the code this guards is all Apple specific, but other platforms
might have the same concerns so I went for a more generic configure
name. Someone who is more familiar with library embedding on Windows can
handle choosing which of the Windows/Signals.inc behaviors might make sense
to go under this flag.
- This also fixes the proper autoconf'ing of ENABLE_BACKTRACES. The code
expects it to be undefined when disabled, but the autoconf check was just
defining it to 0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189694 91177308-0d34-0410-b5e6-96231b3b80d8
This is a re-commit of r189442; I'll follow up with clang changes.
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189624 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Made UnicodeCharSet a class, perform validity checking inside its
constructor instead of each isCharInSet call, use std::binary_search instead of
own implementation.
This patch comes with a necessary change in clang (sent separately).
Reviewers: jordan_rose, klimek
Reviewed By: klimek
CC: cfe-commits, rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1534
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189582 91177308-0d34-0410-b5e6-96231b3b80d8
The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.
I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189442 91177308-0d34-0410-b5e6-96231b3b80d8
The problem with having DefaultSlabAllocator being a global static is that it is undefined if BumpPtrAllocator
will be usable during global initialization because it is not guaranteed that DefaultSlabAllocator will be
initialized before BumpPtrAllocator is created and used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189433 91177308-0d34-0410-b5e6-96231b3b80d8
Offset in mmap(3) should be aligned to gepagesize(), 64k, or mmap(3) would fail.
TODO: Invetigate places where 4096 would be required as pagesize, or 4096 would satisfy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188903 91177308-0d34-0410-b5e6-96231b3b80d8
allocated by setupterm. Without this, some folks are seeing leaked
memory whenever this routine is called more than once. Thanks to Craig
Topper for the report.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188615 91177308-0d34-0410-b5e6-96231b3b80d8
Clang doesn't support the MSVC __cpuid intrinsic yet, and fixing that is
blocked on some fairly complicated issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188584 91177308-0d34-0410-b5e6-96231b3b80d8
curses.h). Finding these headers is next to impossible. For example, on
Debian systems libtinfo-dev provides the terminfo reading library we
want, but *not* term.h. For the header, you have to use libncurses-dev.
And libncursesw-dev provides a *different* term.h in a different
location!
These headers aren't worth it. We want two functions the signatures of
which are clearly spec'ed in sys-v and other documentation. Just declare
them ourselves and call them. This should fix some debian builders and
provide better support for "minimal" debian systems that do want color
autodetection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188165 91177308-0d34-0410-b5e6-96231b3b80d8
library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.
This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]
It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188160 91177308-0d34-0410-b5e6-96231b3b80d8
Some users (clang, libTooling) require this. After this patch we can remove
the calls to getenv("PWD") from clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188125 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187949 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187907 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187874 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187866 91177308-0d34-0410-b5e6-96231b3b80d8
One use needs to copy the alloca into a std::string, and the other use
is before calling CreateProcess, which is very heavyweight anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187845 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187837 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187826 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187463 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187314 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187313 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187248 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187209 91177308-0d34-0410-b5e6-96231b3b80d8
* 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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187206 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187179 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187042 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186984 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186595 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186587 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186539 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186530 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186511 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186483 91177308-0d34-0410-b5e6-96231b3b80d8
This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186447 91177308-0d34-0410-b5e6-96231b3b80d8
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);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186409 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186016 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the implementation in include/llvm/Support/YAMLTraits.h.
Added a DenseMap type DITypeHashMap in DebugInfo.h:
DenseMap<std::pair<StringRef, unsigned>, MDNode*>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185852 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185726 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185716 91177308-0d34-0410-b5e6-96231b3b80d8
Originally if D.firstSigDigit == str.end(), we will have already dereferenced
D.firstSigDigit in the first predicate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185437 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185184 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185126 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185111 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185099 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185095 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185059 91177308-0d34-0410-b5e6-96231b3b80d8
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().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185036 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184881 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184802 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184711 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184710 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184686 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184584 91177308-0d34-0410-b5e6-96231b3b80d8
IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184579 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184380 91177308-0d34-0410-b5e6-96231b3b80d8
This ports a missing feature from PathV1.h. I am not sure how to test this
with the regular infrastructure, but an Apple bot should check this when
r183985 is reapplied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184119 91177308-0d34-0410-b5e6-96231b3b80d8
This patch also adds a simpler version of sys::fs::remove and a tool_output_file
constructor for when we already have an open file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184095 91177308-0d34-0410-b5e6-96231b3b80d8
This broke for example the 'not' utility, if a directory called
'FileCheck' is executable and in the path before the actual 'FileCheck'.
This patch steals the implementation of the "old" PathV1 canExecute
implementation:
- checks for R_OK (file readable): this is necessary for executing
scripts; we should not regress here unless we have good reasons
- checks for S_ISREG; if we want to get rid of this, we'd need to
change all callers who already made the assumption when depending
on Path V1.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184074 91177308-0d34-0410-b5e6-96231b3b80d8
It looks like clang-tools-extra/unittests/cpp11-migrate/TransformTest.cpp
depends on the behaviour of the old one on Windows. Maybe a difference
between GetCurrentDirectoryA and GetCurrentDirectoryW?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184009 91177308-0d34-0410-b5e6-96231b3b80d8
