| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm-ar is using CompareStringOrdinal which is available
only starting with Windows Vista (WINVER 0x600).
Fix this by hoising WindowsSupport.h, which sets _WIN32_WINNT
to 0x0601, up to llvm/include/llvm/Support and use it in llvm-ar.
Patch by Cristian Adam!
Differential revision: https://reviews.llvm.org/D74599
(cherry picked from commit 01f9abbb50b11dd26b9ccb7cb565cc955d2b9c74)
This is for https://bugs.llvm.org/show_bug.cgi?id=44907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mark the CrashRecoveryContextImpl constructor noexcept, so that MSVC
won't emit an unwind helper to clean up the allocation from `new` if the
constructor throws an exception.
Otherwise, MSVC complains:
llvm\lib\Support\CrashRecoveryContext.cpp(220): error C2712: \
Cannot use __try in functions that require object unwinding
The other simple fix would be to wrap `new` in a static helper or
lambda.
Users have reported that Tensorflow builds LLVM with /EHsc.
(cherry picked from commit a349c09162a8260bdf691c4f7ab72a16c33975f6)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
|
|
|
|
| |
Previously, the SEH codepath in CrashRecoveryContext didn't create a CrashRecoveryContextImpl. The other codepaths (VEH and Unix) were creating it.
When running with -fintegrated-cc1, this is needed to handle exit() as a jump to CrashRecoveryContext's exception filter, through a call to RaiseException. In that situation, we need a user-defined exception code, which is later interpreted as an exit() by the exception filter. This in turn needs to set RetCode accordingly, *inside* the exception filter, and *before* calling HandleCrash().
Differential Revision: https://reviews.llvm.org/D74078
(cherry picked from commit 2a3fa0fc5cd7d3398c0293915b0e569eaa0be24b)
|
|
|
|
|
|
|
|
|
| |
As discussed in D70568, remove this because it isn't used anywhere, and I think it's better to go through real crashes for testing (#pragma clang __debug crash).
Also remove the support function llvm::CrashRecoveryContext::HandleCrash() which was added at the same time by @ddunbar.
Differential Revision: https://reviews.llvm.org/D74063
(cherry picked from commit 8ecde3ac34bbb5a8d53d8ec5cd32867658646df1)
|
|
|
|
| |
(cherry picked from commit 31e07692d7f2b383bd64c63cd2b5c35b6503cf3a)
|
|
|
|
|
|
| |
Patch by Markus Böck.
Differential Revision: https://reviews.llvm.org/D72564
|
|
|
|
|
|
|
|
|
| |
CrashRecoveryContext fails
This patch allows for handling a failure inside a CrashRecoveryContext in the same way as the global exception/signal handler. A failure will have the same side-effect, such as cleanup of temporarty file, printing callstack, calling relevant signal handlers, and finally returning an exception code. This is an optional feature, disabled by default.
This is a support patch for D69825.
Differential Revision: https://reviews.llvm.org/D70568
|
|
|
|
|
|
| |
This reverts commit a36f316390d4bc1bcb0e9de0f55831385ab24099.
I did not intend to push this with the InitializePasses.h change.
|
|
|
|
| |
WIP stats
|
| |
|
|
|
|
|
| |
This reverts commit 7bc7fe6b789d25d48d6dc71d533a411e9e981237.
The immediate callers have been fixed to pass nullopt where appropriate.
|
|
|
|
|
|
| |
Only use a recursive mutex if it can be locked recursively.
llvm-svn: 369295
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46290
llvm-svn: 331272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
We have to check gCrashRecoveryEnabled before using __try.
In other words, SEH works too well and we ended up recovering from
crashes in implicit module builds that we weren't supposed to. Only
libclang is supposed to enable CrashRecoveryContext to allow implicit
module builds to crash.
llvm-svn: 303279
|
|
|
|
|
|
| |
This reverts commit r303274, it appears to break some clang tests.
llvm-svn: 303275
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It avoids problems when other libraries raise exceptions. In particular,
OutputDebugString raises an exception that the debugger is supposed to
catch and suppress. VEH kicks in first right now, and that is entirely
incorrect.
Unfortunately, GCC does not support SEH, so I've kept the old buggy VEH
codepath around. We could fix it with SetUnhandledExceptionFilter, but
that is not per-thread, so a well-behaved library shouldn't set it.
Reviewers: zturner
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33261
llvm-svn: 303274
|
|
|
|
| |
llvm-svn: 303272
|
|
|
|
| |
llvm-svn: 303220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we use AddVectoredExceptionHandler, we get notified of
every exception that gets raised by a program. Sometimes these
are not necessarily errors though, and this can be especially
true when linking against a library that we have no control
over, and may raise an exception internally which it intends
to catch.
In particular, the Windows API OutputDebugString does exactly
this. It raises an exception inside of a __try / __except,
giving the debugger a chance to handle the exception to print
the message to the debug console.
But this doesn't interoperate nicely with our vectored exception
handler, which just sees another exception and decides that we
need to terminate the program.
Add a special case for this so that we ignore ODS exceptions
and continue normally.
Note that a better fix is to simply not use vectored exception
handlers and use SEH instead, but given that MinGW doesn't support
SEH, this is the only solution for MinGW.
Differential Revision: https://reviews.llvm.org/D33260
llvm-svn: 303219
|
|
|
|
|
|
|
|
|
|
| |
files; other minor fixes."
This reverts commit r265454 since it broke the build. E.g.:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/22413/
llvm-svn: 265459
|
|
|
|
|
|
|
|
|
|
|
|
| |
other minor fixes.
Some Include What You Use suggestions were used too.
Use anonymous namespaces in source files.
Differential revision: http://reviews.llvm.org/D18778
llvm-svn: 265454
|
|
|
|
|
|
| |
function always returned an empty string.
llvm-svn: 264458
|
|
|
|
| |
llvm-svn: 250643
|
|
|
|
| |
llvm-svn: 244337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libclang uses a CrashRecoveryContext, and building a module does too. If a
module gets built through libclang, nested CrashRecoveryContexts are used. They
work fine with threads as things are stored in ThreadLocal variables, but in
LLVM_ENABLE_THREADS=OFF builds the two recovery contexts would write to the
same globals.
To fix, keep active CrashRecoveryContextImpls in a list and have the global
point to the innermost one, and do something similar for
tlIsRecoveringFromCrash.
Necessary (but not sufficient) for PR11974 and PR20325
http://reviews.llvm.org/D11770
llvm-svn: 244251
|
|
|
|
|
|
| |
Apparently, the style needs to be agreed upon first.
llvm-svn: 240390
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
|
|
|
|
|
|
| |
NFC.
llvm-svn: 232976
|
|
|
|
|
|
|
|
|
|
|
|
| |
PRIO_DARWIN_BG to the new thread if it is
set on the calling thread.
This allows libclang's indexing threads to propagate their priority to the clang module building threads.
rdar://17459872
llvm-svn: 211747
|
|
|
|
| |
llvm-svn: 210551
|
|
|
|
|
|
| |
which GCC detects and Clang does not!
llvm-svn: 208033
|
|
|
|
| |
llvm-svn: 208030
|
|
|
|
|
|
| |
type-erased reference to a callable object.
llvm-svn: 208025
|
|
|
|
| |
llvm-svn: 205697
|
|
|
|
| |
llvm-svn: 202902
|
|
|
|
| |
llvm-svn: 202895
|
|
|
|
| |
llvm-svn: 201258
|
|
|
|
|
|
|
|
|
|
| |
Mutex and
global ThreadLocals, thereby getting rid of the load-time initialization of those
objects and also getting rid of their destruction unless the LLVM client calls
llvm_shutdown.
llvm-svn: 190617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the thread-local "CurrentContext"
in the "parent" thread, when we are using CrashRecoveryContext::RunSafelyOnThread.
When using CrashRecoveryContext::RunSafelyOnThread, we would set a CrashRecoveryContextImpl* to a thread-local variable
for the "child" thread, but CrashRecoveryContext would erroneously clear it in the "parent" thread.
The result was that if CrashRecoveryContext::RunSafelyOnThread was called again in the "child" thread it would mess up
crash-recovery for its parent.
A test for this will be added in the clang repository.
rdar://14204560
llvm-svn: 184380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
| |
llvm-svn: 155283
|
|
|
|
| |
llvm-svn: 150918
|
|
|
|
|
|
| |
CrashRecoveryContext. Thanks to Aaron Ballman!
llvm-svn: 138199
|
|
|
|
|
|
| |
the buildbot failure earlier.
llvm-svn: 128071
|
|
|
|
|
|
| |
investigate further why this works on my machine and not on others.
llvm-svn: 128065
|