includes both. Deal with feof and ferror potentially being macros.

llvm-svn: 161658

Patch by David Hill.

llvm-svn: 161344

Since the llvm::sys::fs::map_file_pages() support function it relies on
is not yet implemented on Windows, the unit tests for FileOutputBuffer 
are currently conditionalized to run only on unix.

llvm-svn: 161099

llvm-svn: 160897

Function names should be camel case, and start with a lower case letter.  No
functional change intended.

llvm-svn: 160813

Report/patch inspiration by Olaf Krzikalla.

llvm-svn: 160744

llvm-svn: 160643

Remove unused private member variables uncovered by the recent changes to clang's -Wunused-private-field.

llvm-svn: 160583

llvm-svn: 160567

color.

llvm-svn: 160559

llvm-svn: 160558

llvm-svn: 160557

Atom buildbot will auto-detect Atom.

llvm-svn: 160521

It is optimal at least up to 7 bits (I've tested all such cases)
This change to truncate() allows a little simplification to the multiplication code,
and it also makes multiplication optimal :)

llvm-svn: 160512

llvm-svn: 160479

llvm-svn: 160476

when run on an Intel Atom processor. The failures have arisen due
to changes elsewhere in the trunk over the past 8 weeks or so.

These failures were not detected by the Atom buildbot because the
CPU on the Atom buildbot was not being detected as an Atom CPU.
The fix for this problem is in Host.cpp and X86Subtarget.cpp, but
shall remain commented out until the current set of Atom test failures
are fixed.

Patch by Andy Zhang and Tyler Nowicki!

llvm-svn: 160451

llvm-svn: 160368

llvm-svn: 160317

Make it always return APInts with the same bitwidth for the same ConstantRange bitwidth to simply clients

llvm-svn: 160294

llvm-svn: 160142

file buffer is null-terminated.

If the file is smaller than we thought, mmap will not allow dereferencing
past the pages that are enough to cover the actual file size,
even though we asked for a larger address range.

rdar://11612916

llvm-svn: 160075

This caused 6 of 65k possible 8 bit udivs to be wrong.

llvm-svn: 160058

llvm-svn: 159367

llvm-svn: 159352

llvm-svn: 159319

The cpuid registers are only available in privileged mode so we don't have
an OS-independent way of implementing this. ARM doesn't provide a list of
processor IDs so the list is somewhat incomplete.

llvm-svn: 159228

PR13114.

llvm-svn: 159210

Fix 'sys::IdentifyFileType' to work with big and little endian byte orderings
when reading the ELF object file type.

Initial patch by Stefan Hepp.

llvm-svn: 159138

FYI, two arguments of strerror_s() is provided in C++ on msvc.

llvm-svn: 159103

llvm-svn: 158844

llvm-svn: 158841

llvm-svn: 158788

Add permissions(), map_file_pages(), and unmap_file_pages() to llvm::sys::fs and add unit test. Unix is implemented.  Windows side needs to be implemented.

llvm-svn: 158770

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.

llvm-svn: 158769

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. =]

llvm-svn: 158725

llvm-svn: 158704

the address of it. Found by a checking STL implementation used on
a dragonegg builder. Sorry about this one. =/

llvm-svn: 158582

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....

llvm-svn: 158580

llvm-svn: 158405