llvm::RawMemoryObject handles empty ranges just fine, and the assert can
be triggered in the wild by e.g. invoking clang with a file that
included an empty pre-compiled header file when clang has been built
with assertions enabled. Without assertions enabled, clang will properly
report that the empty file is not a valid PCH.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158769 91177308-0d34-0410-b5e6-96231b3b80d8
StringMap suffered from the same bug as DenseMap: when you explicitly
construct it with a small number of buckets, you can arrange for the
tombstone-based growth path to be followed when the number of buckets
was less than '8'. In that case, even with a full map, it would compare
'0' as not less than '0', and refuse to grow the table, leading to
inf-loops trying to find an empty bucket on the next insertion. The fix
is very simple: use '<=' as the comparison. The same fix was applied to
DenseMap as well during its recent refactoring.
Thanks to Alex Bolz for the great report and test case. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158725 91177308-0d34-0410-b5e6-96231b3b80d8
the address of it. Found by a checking STL implementation used on
a dragonegg builder. Sorry about this one. =/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158582 91177308-0d34-0410-b5e6-96231b3b80d8
This is likely only the tip of the ice berg, but this particular bug
caused any double-free on a glibc system to turn into a deadlock! It is
not generally safe to either allocate or release heap memory from within
the signal handler. The 'pop_back()' in RemoveFilesToRemove was deleting
memory and causing the deadlock. What's worse, eraseFromDisk in PathV1
has lots of allocation and deallocation paths. We even passed 'true' in
a place that would have caused the *signal handler* to try to run the
'system' system call and shell out to 'rm -rf'. That was never going to
work...
This patch switches the file removal to use a vector of strings so that
the exact text needed for the 'unlink' system call can be stored there.
It switches the loop to be a boring indexed loop, and directly calls
unlink without looking at the error. It also works quite hard to ensure
that calling 'c_str()' is safe, by ensuring that the non-signal-handling
code path that manipulates the vector always leaves it in a state where
every element has already had 'c_str()' called at least once.
I dunno exactly how overkill this is, but it fixes the
deadlock-on-double free issue, and seems likely to prevent any other
issues from sneaking up.
Sorry for not having a test case, but I *really* don't know how to test
signal handling code easily....
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158580 91177308-0d34-0410-b5e6-96231b3b80d8
POWER4 is a 64-bit CPU (better matched to the 970).
The g3 is really the 750 (no altivec), the g4+ is the 74xx (not the 750).
Patch by Andreas Tobler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158363 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
Move PPC host-CPU detection logic from PPCSubtarget into sys::getHostCPUName().
Both the new Linux functionality and the old Darwin functions have been moved.
This change also allows this information to be queried directly by clang and
other frontends (clang, for example, will now have real -mcpu=native support).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158349 91177308-0d34-0410-b5e6-96231b3b80d8
thread local data, embed them in the class using a uint64_t and make sure
we get compiler errors if there's a platform where this is not big enough.
This makes ThreadLocal more safe for using it in conjunction with CrashRecoveryContext.
Related to crash in rdar://11434201.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158342 91177308-0d34-0410-b5e6-96231b3b80d8
Both the new Linux functionality and the old Darwin functions have been moved.
This change also allows this information to be queried directly by clang and
other frontends (clang, for example, will now have real -mcpu=native support).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158337 91177308-0d34-0410-b5e6-96231b3b80d8
Apart from being slightly cheaper, this fixes a real bug that hits 32 bit
linux systems. When passing a file larger than 2G to be linked (which isn't
that uncommon with large projects such as WebKit), clang's driver checks
if the file exists but the file size doesn't fit in an off_t and stat(2)
fails with EOVERFLOW. Clang then says that the file doesn't exist instead
of passing it to the linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157891 91177308-0d34-0410-b5e6-96231b3b80d8
For the Family 6 switch in sys::getHostCPUName, an unrecognized model was
reported as "i686". That's a really bad default since it means that new
CPUs will be treated as if they can only use 32-bit code. This just looks
at the cpuid extended feature flag for 64 bit support, and if that is set,
it uses a default x86-64 cpu. Similar logic is already used for the Family
15 code. <rdar://problem/11314502>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156486 91177308-0d34-0410-b5e6-96231b3b80d8
This new function provides a way to get the iOS version number from ios triples.
Part of rdar://11409204
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156483 91177308-0d34-0410-b5e6-96231b3b80d8
- Just use sys::Process::GetRandomNumber instead of having two poor
implementations.
- This is ~70 times (!) faster on my OS X machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156238 91177308-0d34-0410-b5e6-96231b3b80d8
The new target machines are:
nvptx (old ptx32) => 32-bit PTX
nvptx64 (old ptx64) => 64-bit PTX
The sources are based on the internal NVIDIA NVPTX back-end, and
contain more functionality than the current PTX back-end currently
provides.
NV_CONTRIB
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156196 91177308-0d34-0410-b5e6-96231b3b80d8
When building LLVM on Linux with libc++ with CMake TIME_WITH_SYS_TIME is
undefined, and HAVE_SYS_TIME_H is defined. This ends up including
sys/time.h but not time.h. Unix/TimeValue.inc requires time.h for asctime_r
and localtime. libstdc++ seems to include time.h anyway, but libc++ does
not.
Fix this by always including time.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155382 91177308-0d34-0410-b5e6-96231b3b80d8
The problem is that the struct file_status on UNIX systems has two
members called st_dev and st_ino; those are also members of the
struct stat, and they are reserved identifiers which can also be
provided as #define (and this is the case for st_dev on Hurd).
The solution (attached) is to rename them, for example adding a
"fs_" prefix (= file status) to them.
Patch by Pino Toscano
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155354 91177308-0d34-0410-b5e6-96231b3b80d8
DenseMap's hash function uses slightly more entropy and reduces hash collisions
significantly. I also experimented with Hashing.h, but it didn't gave a lot of
improvement while being much more expensive to compute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154996 91177308-0d34-0410-b5e6-96231b3b80d8
To be used in printing unprintable source in clang diagnostics.
Patch by Seth Cantrell, with a minor fix for mingw by me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154805 91177308-0d34-0410-b5e6-96231b3b80d8
the caller requested a null-terminated one.
When mapping the file there could be a racing issue that resulted in the file being larger
than the FileSize passed by the caller. We already have an assertion
for this in MemoryBuffer::init() but have a runtime guarantee that
the buffer will be null-terminated, so do a copy that adds a null-terminator.
Protects against crash of rdar://11161822.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154082 91177308-0d34-0410-b5e6-96231b3b80d8
buildbots. Original commit message:
[ADT] Change the trivial FoldingSetNodeID::Add* methods to be inline, reapplied
with a fix for the longstanding over-read of 32-bit pointer values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152304 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a build failure in webkit. Copying all elements shouldn't be
necessary, I'll look out for a better fix soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152252 91177308-0d34-0410-b5e6-96231b3b80d8
This currently assumes that both sets have the same SmallSize to keep the implementation simple,
a limitation that can be lifted if someone cares.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152143 91177308-0d34-0410-b5e6-96231b3b80d8
new hash_value infrastructure, and replace their implementations using
hash_combine. This removes a complete copy of Jenkin's lookup3 hash
function (which is both significantly slower and lower quality than the
one implemented in hash_combine) along with a somewhat scary xor-only
hash function.
Now that APInt and APFloat can be passed directly to hash_combine,
simplify the rest of the LLVMContextImpl hashing to use the new
infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152004 91177308-0d34-0410-b5e6-96231b3b80d8
to do more invasive refactoring here to get FoldingSet to use size_t or
even hash_code directly, but for now this is a good first step to remove
Yet Another Hashing Algorithm from LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151859 91177308-0d34-0410-b5e6-96231b3b80d8
