| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
with a configure-time check for lseek64.
llvm-svn: 289187
|
|
|
|
| |
llvm-svn: 289185
|
|
|
|
| |
llvm-svn: 289184
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a new type-safe general purpose formatting
library. It provides compile-time type safety, does not require
a format specifier (since the type is deduced), and provides
mechanisms for extending the format capability to user defined
types, and overriding the formatting behavior for existing types.
This patch additionally adds documentation for the API to the
LLVM programmer's manual.
Mailing List Thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105836.html
Differential Revision: https://reviews.llvm.org/D25587
llvm-svn: 286682
|
|
|
|
| |
llvm-svn: 286498
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to indent a binary blob by a certain
number of bytes, and also makes some things more idiomatic.
Finally, it integrates this binary blob formatter into ScopedPrinter
which used to have its own implementation of this algorithm.
Differential Revision: https://reviews.llvm.org/D26477
llvm-svn: 286495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unit tests were added to verify this functionality keeps working correctly.
Example output for raw hex bytes:
llvm::ArrayRef<uint8_t> Bytes = ...;
llvm::outs() << format_hex_bytes(Bytes);
554889e5 4881ec70 04000048 8d051002
00004c8d 05fd0100 004c8b0d d0020000
Example output for raw hex bytes with offsets:
llvm::outs() << format_hex_bytes(Bytes, 0x100000d10);
0x0000000100000d10: 554889e5 4881ec70 04000048 8d051002
0x0000000100000d20: 00004c8d 05fd0100 004c8b0d d0020000
Example output for raw hex bytes with ASCII with offsets:
llvm::outs() << format_hex_bytes_with_ascii(Bytes, 0x100000d10);
0x0000000100000d10: 554889e5 4881ec70 04000048 8d051002 |UH.?H.?p...H....|
0x0000000100000d20: 00004c8d 05fd0100 004c8b0d d0020000 |..L..?...L..?...|
The default groups bytes into 4 byte groups, but this can be changed to 1 byte:
llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 16 /*NumPerLine*/, 1 /*ByteGroupSize*/);
0x0000000100000d10: 55 48 89 e5 48 81 ec 70 04 00 00 48 8d 05 10 02
0x0000000100000d20: 00 00 4c 8d 05 fd 01 00 00 4c 8b 0d d0 02 00 00
llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 16 /*NumPerLine*/, 2 /*ByteGroupSize*/);
0x0000000100000d10: 5548 89e5 4881 ec70 0400 0048 8d05 1002
0x0000000100000d20: 0000 4c8d 05fd 0100 004c 8b0d d002 0000
llvm::outs() << format_hex_bytes(Bytes, 0x100000d10, 8 /*NumPerLine*/, 1 /*ByteGroupSize*/);
0x0000000100000d10: 55 48 89 e5 48 81 ec 70
0x0000000100000d18: 04 00 00 48 8d 05 10 02
0x0000000100000d20: 00 00 4c 8d 05 fd 01 00
0x0000000100000d28: 00 4c 8b 0d d0 02 00 00
https://reviews.llvm.org/D26405
llvm-svn: 286316
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This resubmits r284436 and r284437, which were reverted in
r284462 as they were breaking the AArch64 buildbot.
The breakage on AArch64 turned out to be a miscompile which is
still not fixed, but is actively tracked at llvm.org/pr30748.
This resubmission re-writes the code in a way so as to make the
miscompile not happen.
llvm-svn: 285483
|
|
|
|
|
|
|
|
|
|
| |
This reverts commits 284436 and 284437 because they still break AArch64 bots:
Value of: format_number(-10, IntegerStyle::Integer, 1)
Actual: "-0"
Expected: "-10"
llvm-svn: 284462
|
|
|
|
|
|
| |
This should fix the remaining broken builds.
llvm-svn: 284437
|
|
|
|
|
|
|
|
|
|
| |
This resubmits commits 284425 and r284428, which were reverted
in r284429 due to some infinite recursion caused by an incorrect
selection of function overloads. Reproduced the failure on Linux
using GCC 4.8.4, and confirmed that with the new patch the tests
path on GCC as well as MSVC. So hopefully this fixes everything.
llvm-svn: 284436
|
|
|
|
|
|
|
| |
This reverts r288425 and r284428 as they are causing test crashes
on some systems.
llvm-svn: 284429
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
raw_ostream has not afforded a lot of flexibility in terms of
how to format numbers when outputting. Wrap this all up into
a set of low level helper functions that can be used to output
numbers with arbitrary precision, alignment, format, etc and
then update raw_ostream to use these functions.
This will be useful for upcoming improvements to llvm's string
formatting libraries, but are still useful independently.
Differential Revision: https://reviews.llvm.org/D25497
llvm-svn: 284425
|
|
|
|
|
|
|
|
|
|
| |
Low level functionality to format numbers were embedded in the
implementation of raw_ostream. I have need to use these through
an interface other than the overloaded stream operators, so they
need to be raised to a level that they can be used from either
raw_ostream operators or other code.
llvm-svn: 283921
|
|
|
|
|
|
|
|
| |
other minor fixes.
Differential revision: https://reviews.llvm.org/D23789
llvm-svn: 279535
|
|
|
|
|
|
| |
Follow up to r278902. I had missed "fall through", with a space.
llvm-svn: 278970
|
|
|
|
|
|
|
| |
We require C++11 to build, so remove a few remaining preprocessor checks for
'__cplusplus >= 201103L'. This should always be true.
llvm-svn: 264572
|
|
|
|
| |
llvm-svn: 261614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without this, this command
$ llvm-run llc -stop-after machine-cp -o - <( echo '' )
outputs an error, because we close stdout twice -- once when closing the
file opened for "-o", and again when closing outs().
Also clarify in the outs() definition that you can't ever call it if you
want to open your own raw_fd_ostream on stdout.
Reviewers: jroelofs, tstellarAMD
Subscribers: jholewinski, qcolombet, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D17422
llvm-svn: 261286
|
|
|
|
| |
llvm-svn: 260068
|
|
|
|
| |
llvm-svn: 259763
|
|
|
|
| |
llvm-svn: 259762
|
|
|
|
|
|
| |
intead of 20 as that's the largest string a 64-bit hex value can be.
llvm-svn: 259313
|
|
|
|
| |
llvm-svn: 259312
|
|
|
|
|
|
|
|
|
| |
Apparently the preferred version is the incredibly complicated
VerifyVersionInfoW function.
Rename the function to avoid potential future name clashes.
llvm-svn: 257415
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is similar to the Python issue#11395. We need to cap the output
size to 32767 on Windows to work around the size limit of WriteConsole().
Reference: https://bugs.python.org/issue11395
Writing a test for this bug turns out to be harder than I thought. I am
still working on it (see phabricator review D15705).
Differential Revision: http://reviews.llvm.org/D15553
llvm-svn: 256892
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like the code this patch deletes is based on a misunderstanding of
what guarantees writev provides. In particular, writev with 1 iovec is
not "more atomic" than a write.
Testing on OS X shows that both write and writev from multiple processes
can be intermixed.
llvm-svn: 255837
|
|
|
|
|
|
|
|
| |
This commit provoked "error C2593: 'operator <<' is ambiguous" on MSVC.
This reverts commit r254655.
llvm-svn: 254661
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows easier construction of print helpers. Example:
Printable PrintLaneMask(unsigned LaneMask) {
return Printable([LaneMask](raw_ostream &OS) {
OS << format("%08X", LaneMask);
});
}
// Usage:
OS << PrintLaneMask(Mask);
Differential Revision: http://reviews.llvm.org/D14348
llvm-svn: 254655
|
|
|
|
| |
llvm-svn: 244924
|
|
|
|
|
|
|
|
|
| |
This is faster and avoids the stream and SmallString state synchronization issue.
resync() is a no-op and may be safely deleted. I'll do so in a follow-up commit.
Reviewed by Rafael Espindola.
llvm-svn: 244870
|
|
|
|
| |
llvm-svn: 238647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementations could exhibit some behavior differences:
raw_fd_ostream: Whatever the underlying fd does with seek+write. In a normal
file, the write position would be back to the old offset.
raw_svector_ostream: The write position is always the end of the stream, so
after pwrite the write position would be the new end. This matches what OS_X
(all BSD?) do with a pwrite in a O_APPEND fd.
Given that we don't need that feature and don't use O_APPEND a lot in LLVM,
just disallow it.
I am open to suggestions on renaming pwrite to something else, but this fixes
the issue for now.
Thanks to Yaron Keren for reporting it.
llvm-svn: 235303
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now we don't have to do 2 synchronized passes to compute offsets and then
write the file.
This also includes a fix for the corner case of seeking in /dev/null. It
is not an error, but on some systems (Linux) the returned offset is
always 0. An error is signaled by returning -1. This is checked by
the existing tests now that "clang -o /dev/null ..." seeks.
llvm-svn: 234952
|
|
|
|
|
|
|
| |
This is a raw_ostream that also supports pwrite.
I will be used in a sec.
llvm-svn: 234895
|
|
|
|
|
|
| |
Will be tested by existing tests once used (soon).
llvm-svn: 234737
|
|
|
|
|
|
|
|
|
|
|
| |
Original message.
Have one raw_fd_ostream constructor forward to the other.
This fixes some odd behaviour differences between the two. In particular,
the version that takes a FD no longer unconditionally sets stdout to binary.
llvm-svn: 234734
|
|
|
|
|
|
|
|
|
| |
It broke MSVCRT hosts:
LLVM :: Object/check_binary_output.ll
LLVM :: Object/extract.ll
llvm-svn: 234721
|
|
|
|
|
|
| |
It will be used in clang in a sec.
llvm-svn: 234619
|
|
|
|
|
|
|
| |
This fixes some odd behavior differences between the two. In particular,
the version that takes a FD no longer unconditionally sets stdout to binary.
llvm-svn: 234615
|
|
|
|
|
|
| |
These were lost when I reverted the raw_ostream changes.
llvm-svn: 234504
|
|
|
|
|
|
|
|
|
| |
Revert "Add classof implementations to the raw_ostream classes."
Revert "Use the cast machinery to remove dummy uses of formatted_raw_ostream."
The underlying issue can be fixed without classof.
llvm-svn: 234495
|
|
|
|
|
|
| |
More uses to follow in a another patch.
llvm-svn: 234460
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces a subset of C++14 integer sequences in STLExtras. This is
just enough to support unpacking a std::tuple into the arguments of
snprintf, we can add more of it when it's actually needed.
Also removes an ancient macro hack that leaks a macro into the global
namespace. Clean up users that made use of the convenient hack.
llvm-svn: 229337
|
|
|
|
|
|
|
|
|
|
| |
Previously using format_hex() would always print a 0x prior to the
hex characters. This allows this to be optional, so that one can
choose to print (e.g.) 255 as either 0xFF or just FF.
Differential Revision: http://reviews.llvm.org/D7151
llvm-svn: 227108
|
|
|
|
|
|
|
|
|
| |
Clang's static analyzer found several potential cases of undefined
behavior, use of un-initialized values, and potentially null pointer
dereferences in tablegen, Support, MC, and ADT. This cleans them up
with specific assertions on the assumptions of the code.
llvm-svn: 224154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most Unix-like operating systems guarantee that the file descriptor is
closed after a call to close(2), even if close comes back with EINTR.
For these systems, calling close _again_ will either do nothing or close
some other file descriptor open(2)'d by another thread. (Linux)
However, some operating systems do not have this behavior. They require
at least another call to close(2) before guaranteeing that the
descriptor is closed. (HP-UX)
And some operating systems have an unpredictable blend of the two
behaviors! (xnu)
Avoid this disaster by blocking all signals before we call close(2).
This ensures that a signal will not be delivered to the thread and
close(2) will not give us back EINTR. We restore the signal mask once
the operation is done.
N.B. This isn't a problem on Windows, it doesn't have a notion of EINTR
because signals always get delivered to dedicated signal handling
threads.
llvm-svn: 219189
|
|
|
|
|
|
|
| |
Don't negate signed integer types in &raw_ostream::operator<<(const
FormattedNumber &FN).
llvm-svn: 218496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::format() is somewhat unsafe. The compiler does not check that integer
parameter size matches the %x or %d size and it does not complain when a
StringRef is passed for a %s. And correctly using a StringRef with format() is
ugly because you have to convert it to a std::string then call c_str().
The cases where llvm::format() is useful is controlling how numbers and
strings are printed, especially when you want fixed width output. This
patch adds some new formatting functions to raw_streams to format numbers
and StringRefs in a type safe manner. Some examples:
OS << format_hex(255, 6) => "0x00ff"
OS << format_hex(255, 4) => "0xff"
OS << format_decimal(0, 5) => " 0"
OS << format_decimal(255, 5) => " 255"
OS << right_justify(Str, 5) => " foo"
OS << left_justify(Str, 5) => "foo "
llvm-svn: 218463
|
|
|
|
|
|
|
|
|
|
| |
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
|