Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

[Support] Creation of minidump after compiler crash on Windows

In the current implementation compiler only prints stack trace
to console after crash. This patch adds saving of minidump
files which c

[Support] Creation of minidump after compiler crash on Windows

In the current implementation compiler only prints stack trace
to console after crash. This patch adds saving of minidump
files which contain a useful subset of the information for
further debugging.

Differential Revision: http://reviews.llvm.org/D18216

llvm-svn: 268519

show more ...

Assert that Process::FindInEnvPath() is passed a relative path.

It misbehaves with absolute paths. (So does path::append().)
Goes with clang r235787.

llvm-svn: 235788

[Support] Remove statically initialized yet dead code.

The last user of this code vanished with r223368, but this function still was
around being executed on every process start, allocating some mem

[Support] Remove statically initialized yet dead code.

The last user of this code vanished with r223368, but this function still was
around being executed on every process start, allocating some memory and then
never being used again. No functional change.

Also avoids occasional complaints about the benign leak in this function, like
PR23037.

llvm-svn: 233371

show more ...

Purge unused includes throughout libSupport.

NFC.

llvm-svn: 232976

Remove dead code. NFC.

This interface was added 2 years ago but users never developed.

llvm-svn: 223368

Refactor the code in clang to find a file in a PATH like environment variable into a helper function

llvm-svn: 212057

Fix .cpp files claiming to be header files

llvm-svn: 211334

Disable Visual C++ warning 4722 about aborting a destructor,
it has no value for us.

llvm-svn: 204704

Hopefully fixing the MinGW 32 build, which was broken by r200767. Not using rand_s() since MinGW does not have an implementation for it, but instead using the underlying CryptGenRandom APIs.

llvm-sv

Hopefully fixing the MinGW 32 build, which was broken by r200767. Not using rand_s() since MinGW does not have an implementation for it, but instead using the underlying CryptGenRandom APIs.

llvm-svn: 201124

show more ...

Implemented support for Process::GetRandomNumber on Windows.

Patch thanks to Stephan Tolksdorf!

llvm-svn: 200767

Support ANSI escape code on Windows

In some cases (e.g. when a build system pipes stderr) the Windows console
API cannot be used to color output. For these, provide a way to switch to
ANSI escape co

Support ANSI escape code on Windows

In some cases (e.g. when a build system pipes stderr) the Windows console
API cannot be used to color output. For these, provide a way to switch to
ANSI escape codes. This is required for Clang's -fansi-escape-codes option.

llvm-svn: 190460

show more ...

Add time getters to the process interface for requesting the elapsed
wall time, user time, and system time since a process started.

For walltime, we currently use TimeValue's interface and a global

Add time getters to the process interface for requesting the elapsed
wall time, user time, and system time since a process started.

For walltime, we currently use TimeValue's interface and a global
initializer to compute a close approximation of total process runtime.

For user time, this adds support for an somewhat more precise timing
mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock
selected.

For system time, we have to do a full getrusage call to extract the
system time from the OS. This is expensive but unavoidable.

In passing, clean up the implementation of the old APIs and fix some
latent bugs in the Windows code. This might have manifested on Windows
ARM systems or other systems with strange 64-bit integer behavior.

The old API for this both user time and system time simultaneously from
a single getrusage call. While this results in fewer system calls, it
also results in a lower precision user time and if only user time is
desired, it introduces a higher overhead. It may be worthwhile to switch
some of the pass timers to not track system time and directly track user
and wall time. The old API also tracked walltime in a confusing way --
it just set it to the current walltime rather than providing any measure
of wall time since the process started the way buth user and system time
are tracked. The new API is more consistent here.

The plan is to eventually implement these methods for a *child* process
by using the wait3(2) system call to populate an rusage struct
representing the whole subprocess execution. That way, after waiting on
a child process its stats will become accurate and cheap to query.

llvm-svn: 171551

show more ...

Resort the #include lines in include/... and lib/... with the
utils/sort_includes.py script.

Most of these are updating the new R600 target and fixing up a few
regressions that have creeped in since

Resort the #include lines in include/... and lib/... with the
utils/sort_includes.py script.

Most of these are updating the new R600 target and fixing up a few
regressions that have creeped in since the last time I sorted the
includes.

llvm-svn: 171362

show more ...

Go ahead and get rid of the old page size interface and convert all the
users over to the new one. No sense maintaining this "compatibility"
layer it seems.

llvm-svn: 171331

Flesh out a page size accessor in the new API.

Implement the old API in terms of the new one. This simplifies the
implementation on Windows which can now re-use the self_process's once
initializatio

Flesh out a page size accessor in the new API.

Implement the old API in terms of the new one. This simplifies the
implementation on Windows which can now re-use the self_process's once
initialization.

llvm-svn: 171330

show more ...

Switch this code to a more idiomatic double using namespace directive.

Fix a truly odd namespace qualifier that was flat out wrong in the
process. The fully qualified namespace would have been
llvm:

Switch this code to a more idiomatic double using namespace directive.

Fix a truly odd namespace qualifier that was flat out wrong in the
process. The fully qualified namespace would have been
llvm::sys::TimeValue, llvm::TimeValue makes no sense.

llvm-svn: 171292

show more ...

Delete a cut/paste-o from r171290. Very sorry about the noise.

llvm-svn: 171291

Suppress a MSVC warning complaining about the code working as intended.

llvm-svn: 171290

Begin sketching out the process interface.

The coding style used here is not LLVM's style because this is modeled
after a Boost interface and thus done in the style of a candidate C++
standard libra

Begin sketching out the process interface.

The coding style used here is not LLVM's style because this is modeled
after a Boost interface and thus done in the style of a candidate C++
standard library interface. I'll probably end up proposing it as
a standard C++ library if it proves to be reasonably portable and
useful.

This is just the most basic parts of the interface -- getting the
process ID out of it. However, it helps sketch out some of the boiler
plate such as the base class, derived class, shared code, and static
factory function. It also introduces a unittest so that I can
incrementally ensure this stuff works.

However, I've not even compiled this code for Windows yet. I'll try to
fix any Windows fallout from the bots, and if I can't fix it I'll revert
and get someone on Windows to help out. There isn't a lot more that is
mandatory, so soon I'll switch to just stubbing out the Windows side and
get Michael Spencer to help with implementation as he can test it
directly.

llvm-svn: 171289

show more ...

Support/Process: Move llvm::sys::Process::GetRandomNumber() from Process.cpp to Unix/Process.inc.

FIXME: GetRandomNumber() is not implemented in Win32.
llvm-svn: 156251

[Support] Add missing include.

llvm-svn: 156240

[Support] Add sys::Process::GetRandomNumber().
- Primitive API, but we rarely have need for random numbers.

llvm-svn: 156237

Merge System into Support.

llvm-svn: 120298