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
sys::fs::unique_file will now loop infinitely if provided with a file name
without '%' characters and the input file already exists. As a result, bugpoint
cannot use a fixed file name for the execution output (including the reference
output).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185166 91177308-0d34-0410-b5e6-96231b3b80d8
It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183864 91177308-0d34-0410-b5e6-96231b3b80d8
BitVector/SmallBitVector::reference::operator bool remain implicit since
they model more exactly a bool, rather than something else that can be
boolean tested.
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
One behavior change (YAMLParser) was made, though no test case is
included as I'm not sure how to reach that code path. Essentially any
comparison of llvm::yaml::document_iterators would be invalid if neither
iterator was at the end.
This helped uncover a couple of bugs in Clang - test cases provided for
those in a separate commit along with similar changes to `operator bool`
instances in Clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181868 91177308-0d34-0410-b5e6-96231b3b80d8
On freebsd this makes sure that symbols are exported on the binaries that need
them. The net result is that we should get symbols in the binaries that need
them on every platform.
On linux x86-64 this reduces the size of the bin directory from 262MB to 250MB.
Patch by Stephen Checkoway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178725 91177308-0d34-0410-b5e6-96231b3b80d8
that work on the LLVMBuild based dependency specification didn't
actually work, we just now maintain dependencies in *3* places instead
of 2. Yay.
There may still be some missing dependencies, I'm still sifting through
the bots and my builds, but this is a step in the right direction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177988 91177308-0d34-0410-b5e6-96231b3b80d8
its own library. These functions are bridging between the bitcode reader
and the ll parser which are in different libraries. Previously we didn't
have any good library to do this, and instead played fast and loose with
a "header only" set of interfaces in the Support library. This really
doesn't work well as evidenced by the recent attempt to add timing logic
to the these routines.
As part of this, make them normal functions rather than weird inline
functions, and sink the implementation into the library. Also clean up
the header to be nice and minimal.
This requires updating lots of build system dependencies to specify that
the IRReader library is needed, and several source files to not
implicitly rely upon the header file to transitively include all manner
of other headers.
If you are using IRReader.h, this commit will break you (the header
moved) and you'll need to also update your library usage to include
'irreader'. I will commit the corresponding change to Clang momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177971 91177308-0d34-0410-b5e6-96231b3b80d8
Change messages to help identify which interpreter was actually selected (safe
vs testing).
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Chandler Carruth <chandlerc@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173360 91177308-0d34-0410-b5e6-96231b3b80d8
Set the message returned after the GCC runner has been constructed as otherwise
the message will be overwritten by the construction of the runner, resulting in
misleading messages.
Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Chandler Carruth <chandlerc@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173359 91177308-0d34-0410-b5e6-96231b3b80d8
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169252 91177308-0d34-0410-b5e6-96231b3b80d8
