| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::report_fatal_error() generate preprocessed source + reproducer.sh again.
Added a test for #pragma clang __debug llvm_fatal_error to test for the original issue.
Added llvm::sys::Process::Exit() and replaced ::exit() in places where it was appropriate. This new function would call the current CrashRecoveryContext if one is running on the same thread; or call ::exit() otherwise.
Fixes PR44705.
Differential Revision: https://reviews.llvm.org/D73742
(cherry picked from commit faace365088a2a3a4cb1050a9facfc34a7a56577)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
| |
|
|
|
|
|
| |
That way users can set the default to true, but then disable core dumps
from certain apps that link support.
llvm-svn: 340588
|
| |
|
|
|
|
|
|
|
| |
secondly coreFilesPrevented.
The previous change ignored the latter resulting in crash dumps being generated when LLVM_ENABLE_CRASH_DUMPS was
set, but coreFilesPrevented was true.
llvm-svn: 340561
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since crash dumping landed in r268519, May 2016, I have not once seen
anyone use an uploaded minidump to debug a compiler crash. Therefore,
I'm turning this off by default. The dumps clutter up user and buildbot
temp directories. Each file is only about 56KB, but it adds up.
In the context of clang, the extra line about the minidump confuses
users, when what we really want from them is the pre-processed source
code.
llvm-svn: 340185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See r331124 for how I made a list of files missing the include.
I then ran this Python script:
for f in open('filelist.txt'):
f = f.strip()
fl = open(f).readlines()
found = False
for i in xrange(len(fl)):
p = '#include "llvm/'
if not fl[i].startswith(p):
continue
if fl[i][len(p):] > 'Config':
fl.insert(i, '#include "llvm/Config/llvm-config.h"\n')
found = True
break
if not found:
print 'not found', f
else:
open(f, 'w').write(''.join(fl))
and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p`
and tried to fix include ordering and whatnot.
No intended behavior change.
llvm-svn: 331184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
This moves over all uses of the macro, but doesn't remove the definition
of it in (llvm-)config.h yet.
llvm-svn: 331127
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously we would only look in the current directory for a
resource, which might not be the same as the directory of the
rc file. Furthermore, MSVC rc supports a /I option, and can
also look in the system environment. This patch adds support
for this search algorithm.
Differential Revision: https://reviews.llvm.org/D38740
llvm-svn: 315499
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
It misbehaves with absolute paths. (So does path::append().)
Goes with clang r235787.
llvm-svn: 235788
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 232976
|
| |
|
|
|
|
| |
This interface was added 2 years ago but users never developed.
llvm-svn: 223368
|
| |
|
|
|
|
| |
variable into a helper function
llvm-svn: 212057
|
| |
|
|
| |
llvm-svn: 211334
|
| |
|
|
|
|
| |
it has no value for us.
llvm-svn: 204704
|
| |
|
|
|
|
| |
rand_s() since MinGW does not have an implementation for it, but instead using the underlying CryptGenRandom APIs.
llvm-svn: 201124
|
| |
|
|
|
|
| |
Patch thanks to Stephan Tolksdorf!
llvm-svn: 200767
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
users over to the new one. No sense maintaining this "compatibility"
layer it seems.
llvm-svn: 171331
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 171291
|
| |
|
|
| |
llvm-svn: 171290
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
to Unix/Process.inc.
FIXME: GetRandomNumber() is not implemented in Win32.
llvm-svn: 156251
|
| |
|
|
| |
llvm-svn: 156240
|
| |
|
|
|
|
| |
- Primitive API, but we rarely have need for random numbers.
llvm-svn: 156237
|
|
|
llvm-svn: 120298
|
