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
Execute's Data parameter is now optional, so we won't allocate memory
for it on Windows and we'll close the process handle.
The Unix code should probably do something similar to avoid accumulation
of zombie children that haven't been waited on.
Tested on Linux and Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183906 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
`typeinfo for llvm:🆑:GenericOptionValue').
Remove an "anchor" method for an abstract class. (This does not
increase the number of vtables.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183830 91177308-0d34-0410-b5e6-96231b3b80d8
Most clients have already been moved from Path V1 to V2. The ones using V1
now include PathV1.h explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183801 91177308-0d34-0410-b5e6-96231b3b80d8
For ARM on linux we use /proc/cpuinfo to detect the host CPU's features.
Linux derives these values without ever looking at the vendor of the
specific CPU implementation. Hence, it adds little value, if we parse
the output of /proc/cpuinfo only for certain vendors.
This patch enables us to derive the correct feature flags e.g. for Qualcomm
CPUs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183790 91177308-0d34-0410-b5e6-96231b3b80d8
It will be tested in the next commit which moves another user to identify_magic.
Original message:
Fix an out of bounds array access.
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183753 91177308-0d34-0410-b5e6-96231b3b80d8
We were looking at Magic[5] without checking Length. Since this path would not
return unless Length >= 18 anyway, just move the >= 18 check up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183666 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed in clang so one can check if the object needs the
destructor called after its memory was freed. This is useful when
creating many APInt/APFloat objects with placement new, where the
overhead of tracking the pointers for cleanup is significant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183100 91177308-0d34-0410-b5e6-96231b3b80d8
Add a stringize method to make dumping a bit easier, and add a testcase
exercising a few different paths.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182692 91177308-0d34-0410-b5e6-96231b3b80d8
There was exactly one caller using this API right, the others were relying on
specific behavior of the default implementation. Since it's too hard to use it
right just remove it and standardize on the default behavior.
Defines away PR16132.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182636 91177308-0d34-0410-b5e6-96231b3b80d8
This patch builds on some existing code to do CFG reconstruction from
a disassembled binary:
- MCModule represents the binary, and has a list of MCAtoms.
- MCAtom represents either disassembled instructions (MCTextAtom), or
contiguous data (MCDataAtom), and covers a specific range of addresses.
- MCBasicBlock and MCFunction form the reconstructed CFG. An MCBB is
backed by an MCTextAtom, and has the usual successors/predecessors.
- MCObjectDisassembler creates a module from an ObjectFile using a
disassembler. It first builds an atom for each section. It can also
construct the CFG, and this splits the text atoms into basic blocks.
MCModule and MCAtom were only sketched out; MCFunction and MCBB were
implemented under the experimental "-cfg" llvm-objdump -macho option.
This cleans them up for further use; llvm-objdump -d -cfg now generates
graphviz files for each function found in the binary.
In the future, MCObjectDisassembler may be the right place to do
"intelligent" disassembly: for example, handling constant islands is just
a matter of splitting the atom, using information that may be available
in the ObjectFile. Also, better initial atom formation than just using
sections is possible using symbols (and things like Mach-O's
function_starts load command).
This brings two minor regressions in llvm-objdump -macho -cfg:
- The printing of a relocation's referenced symbol.
- An annotation on loop BBs, i.e., which are their own successor.
Relocation printing is replaced by the MCSymbolizer; the basic CFG
annotation will be superseded by more related functionality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182628 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a bootstrapping problem with builds for Apple ARM targets.
Clang had the wrong prototype for __clear_cache with ARM targets. Rafael
fixed that in clang svn r181784 and r181810, but without those changes,
we can't build this code for ARM because clang reports an error about the
declaration in Memory.inc not matching the builtin declaration. Some of our
buildbots need to use an older compiler that doesn't have the clang fix.
Since __clear_cache is never used here when __APPLE__ is defined, I'm just
conditionalizing the declaration to match that. I also moved the declaration
of sys_icache_invalidate inside the conditional for __APPLE__ while I was at
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182223 91177308-0d34-0410-b5e6-96231b3b80d8
lli's remote MCJIT code calls setExecutable just prior to running
code. In line with Darwin behaviour this seems to be the place to
invalidate any caches needed so that relocations can take effect
properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182213 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
GCC declares __clear_cache in the gnu modes (-std=gnu++98,
-std=gnu++11), but not in the strict modes (-std=c++98, -std=c++11). This patch
declares it and therefore fixes the build when using one of the strict modes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181785 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch allows using \n inside long help strings for command-line
options, so that all lines are equally indented. This is not a perfect solution,
as we don't (and probably don't want to) know about terminal width, but it
allows to format long help strings somehow readable without manually padding
them with spaces. A motivating example is -help output from clang-format (source
code in tools/clang-format/ClangFormat.cpp, see cl options offset, length,
style, and dump-config).
Reviewers: atrick, alexfh
Reviewed By: alexfh
CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D779
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181608 91177308-0d34-0410-b5e6-96231b3b80d8
- previously formatted_raw_ostream tracked columns, now it tracks lines too
- used by (upcoming) DebugIR pass to know the line number to connect to each IR
instruction
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181463 91177308-0d34-0410-b5e6-96231b3b80d8
AArch64 is going to need some kind of cache-invalidation in order to
successfully JIT since it has a weak memory-model. This is provided by
a __clear_cache builtin in libgcc, which acts very much like the
32-bit ARM equivalent (on platforms where it exists).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181129 91177308-0d34-0410-b5e6-96231b3b80d8
The intended semantics mirror autoconf, where the user is able to
specify a host triple, but if it's left to the build system then
"config.guess" is invoked for the default.
This also renames the LLVM_HOSTTRIPLE define to LLVM_HOST_TRIPLE to
fit in with the style of the surrounding defines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181112 91177308-0d34-0410-b5e6-96231b3b80d8
The llvm::sys::AddSignalHandler function (as well as related routines) in
lib/Support/Unix/Signals.inc currently registers a signal handler routine
via "sigaction". When this handler is called due to a SIGSEGV, SIGILL or
similar signal, it will show a stack backtrace, deactivate the handler,
and then simply return to the operating system. The intent is that the
OS will now retry execution at the same location as before, which ought
to again trigger the same error condition and cause the same signal to be
delivered again. Since the hander is now deactivated, the OS will take
its default action (usually, terminate the program and possibly create
a core dump).
However, this method doesn't work reliably on System Z: With certain
signals (namely SIGILL, SIGFPE, and SIGTRAP), the program counter stored
by the kernel on the signal stack frame (which is the location where
execution will resume) is not the instruction that triggered the fault,
but then instruction *after it*. When the LLVM signal handler simply
returns to the kernel, execution will then resume at *that* address,
which will not trigger the problem again, but simply go on and execute
potentially unrelated code leading to random errors afterwards.
To fix this, the patch simply goes and re-raises the signal in question
directly from the handler instead of returning from it. This is done
only on System Z and only for those signals that have this particular
problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181010 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is http://llvm.org/PR15802. Backslashes preceding double quotes in
arguments must be escaped. The interesting bit is that all other
backslashes should *not* be escaped, because the un-escaping logic is
only triggered by the presence of a double quote character.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D705
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180035 91177308-0d34-0410-b5e6-96231b3b80d8
I will remove the isBigEndianHost function once I update clang.
The ifdef logic is designed to
* not use configure/cmake to avoid breaking -arch i686 -arch ppc.
* default to little endian
* be as small as possible
It looks like sys/endian.h is the preferred header on most modern BSD systems,
but it is better to change this in a followup patch as machine/endian.h is
available on FreeBSD, OpenBSD, NetBSD and OS X.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179527 91177308-0d34-0410-b5e6-96231b3b80d8
This will be used in clang to decide if it should create an @file or not. It
will be tested on the clang side.
Patch by Nathan Froyd.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179285 91177308-0d34-0410-b5e6-96231b3b80d8
It's possible for the lock file to disappear and the owning process to
return before we're able to see the generated file. Spin for a little
while to see if it shows up before failing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178909 91177308-0d34-0410-b5e6-96231b3b80d8
If the directory that will contain the unique file doesn't exist when
we tried to create the file, but another process creates it before we
get a chance to try creating it, we would bail out rather than try to
create the unique file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178908 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Sets a report hook that emulates pressing "retry" in the "abort, retry,
ignore" dialog box that _CrtDbgReport normally raises. There are many
other ways to disable assertion reports, but this was the only way I
could find that still calls our exception handler.
Reviewers: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D625
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178880 91177308-0d34-0410-b5e6-96231b3b80d8
when getting the host processor information. It emits a .byte sequence on GNUC compilers to work around lack of xgetbv support with older assemblers, and resolves a comment typo found in the previous patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178636 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 617330909f.
It broke the bots:
/home/clangbuild2/clang-ppc64-2/llvm.src/unittests/ADT/SmallVectorTest.cpp:150: PushPopTest
/home/clangbuild2/clang-ppc64-2/llvm.src/unittests/ADT/SmallVectorTest.cpp:118: Failure
Value of: v[i].getValue()
Actual: 0
Expected: value
Which is: 2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178334 91177308-0d34-0410-b5e6-96231b3b80d8
if execution failed. ExecuteAndWait returns -1 upon an execution failure, but
checking the return value isn't sufficient because the wait command may
return -1 as well. This new parameter is to be used by the clang driver in a
subsequent commit.
Part of rdar://13362359
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178087 91177308-0d34-0410-b5e6-96231b3b80d8
it's only really useful if you're going to crash anyways. Use it in the pretty stack trace
printer to kill the compiler if we hang while printing the stack trace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177962 91177308-0d34-0410-b5e6-96231b3b80d8
-time-ir-parsing flag
This breaks the layering of the Support library. We can't add an
implementation side to IRReader because it refers directly to entities
only accessible as part of the IR, AsmParser, and BitcodeReader
libraries. It can only be used in a context where all of those libraries
will be available.
We'll need to find some other way to get this functionality, and
hopefully solve the long-standing layering problem of IRReader.h...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177695 91177308-0d34-0410-b5e6-96231b3b80d8
The DARWIN_USER_TEMP_DIR and DARWIN_USER_CACHE_DIR configuration
settings are more idiomatic for Darwin than the TMPDIR environment
variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177669 91177308-0d34-0410-b5e6-96231b3b80d8
Clients of MemoryBuffer::getOpenFile expect it not to take ownership of the file
descriptor passed in. So don't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176995 91177308-0d34-0410-b5e6-96231b3b80d8
