| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 186018
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 185861
|
|
|
|
|
|
| |
Ubuntu installs this as xdot, so finding xdot.py would fail.
llvm-svn: 185860
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 185834
|
|
|
|
|
|
| |
Not intended functionality change.
llvm-svn: 185830
|
|
|
|
| |
llvm-svn: 185728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 185719
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185606
|
|
|
|
| |
llvm-svn: 185605
|
|
|
|
| |
llvm-svn: 185603
|
|
|
|
|
|
| |
Patch by pashev.igor.
llvm-svn: 185601
|
|
|
|
|
|
|
| |
Originally if D.firstSigDigit == str.end(), we will have already dereferenced
D.firstSigDigit in the first predicate.
llvm-svn: 185437
|
|
|
|
|
|
|
|
| |
terminators.
rdar://14323230
llvm-svn: 185397
|
|
|
|
| |
llvm-svn: 185226
|
|
|
|
|
|
| |
Hopefully, this fixes the PPC64 buildbots.
llvm-svn: 185218
|
|
|
|
|
|
|
|
| |
- Use static functions instead of anonymous namespace.
- Appease the Doxygen lobby.
- Use 0-based induction variable.
llvm-svn: 185185
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 185141
|
|
|
|
| |
llvm-svn: 185136
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
| |
llvm-svn: 185123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
either zero/NaN but allowed you to arbitrarily set the category of the float.""
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
zero/NaN but allowed you to arbitrarily set the category of the float."
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
but allowed you to arbitrarily set the category of the float.
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
|
|
|
|
| |
llvm-svn: 185015
|
|
|
|
|
|
| |
Patch by 罗勇刚(Yonggang Luo).
llvm-svn: 184971
|
|
|
|
| |
llvm-svn: 184960
|
|
|
|
|
|
| |
bots :-(
llvm-svn: 184920
|
|
|
|
| |
llvm-svn: 184917
|
|
|
|
| |
llvm-svn: 184916
|
|
|
|
|
|
| |
I will remove the V1 version as soon as I change clang in the next commit.
llvm-svn: 184914
|
|
|
|
| |
llvm-svn: 184910
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 184853
|
|
|
|
| |
llvm-svn: 184852
|
|
|
|
| |
llvm-svn: 184826
|
|
|
|
| |
llvm-svn: 184824
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
{inf,-inf,NaN,-NaN}.
llvm-svn: 184713
|
|
|
|
|
|
| |
of them.
llvm-svn: 184712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
only access the significand of FiniteNonZero/NaN floats.
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
what APFloat is actually using said macro for.
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
|
|
|
|
|
|
|
|
| |
frequency with a branch probability."
This reverts commit r184584. Breaks PPC selfhost.
llvm-svn: 184590
|