Commit Graph

52 Commits

Author SHA1 Message Date
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Nico Weber 712e8d29c4 s/LLVM_ON_WIN32/_WIN32/, llvm
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
2018-04-29 00:45:03 +00:00
Serge Pavlov d48042efa8 Report fatal error in the case of out of memory
This is partial recommit of r325224, reverted in 325227. The relevant
part of original comment is below.

Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.

Usual programming practice does not require checking result of 'operator
new' because it throws 'std::bad_alloc' in the case of allocation error.
However, LLVM is usually built with exceptions turned off, so 'new' can
return null pointer. This change installs custom new handler, which causes
fatal error in the case of out of memory. The handler is installed
automatically prior to call to 'main' during construction of a static
object defined in 'lib/Support/ErrorHandling.cpp'. If the application does
not use this file, the handler may be installed manually by a call to
'llvm::install_out_of_memory_new_handler', declared in
'include/llvm/Support/ErrorHandling.h".

Differential Revision: https://reviews.llvm.org/D43010

llvm-svn: 325426
2018-02-17 10:21:33 +00:00
Serge Pavlov 4500001905 Revert r325224 "Report fatal error in the case of out of memory"
It caused fails on some buildbots.

llvm-svn: 325227
2018-02-15 09:45:59 +00:00
Serge Pavlov 431502a675 Report fatal error in the case of out of memory
Analysis of fails in the case of out of memory errors can be tricky on
Windows. Such error emerges at the point where memory allocation function
fails, but manifests itself when null pointer is used. These two points
may be distant from each other. Besides, next runs may not exhibit
allocation error.

Usual programming practice does not require checking result of 'operator
new' because it throws 'std::bad_alloc' in the case of allocation error.
However, LLVM is usually built with exceptions turned off, so 'new' can
return null pointer. This change installs custom new handler, which causes
fatal error in the case of out of memory. The handler is installed
automatically prior to call to 'main' during construction of a static
object defined in 'lib/Support/ErrorHandling.cpp'. If the application does
not use this file, the handler may be installed manually by a call to
'llvm::install_out_of_memory_new_handler', declared in
'include/llvm/Support/ErrorHandling.h".

There are calls to C allocation functions, malloc, calloc and realloc.
They are used for interoperability with C code, when allocated object has
variable size and when it is necessary to avoid call of constructors. In
many calls the result is not checked against null pointer. To simplify
checks, new functions are defined in the namespace 'llvm' with the
same names as these C function. These functions produce fatal error if
allocation fails. User should use 'llvm::malloc' instead of 'std::malloc'
in order to use the safe variant. This change replaces 'std::malloc'
in the cases when the result of allocation function is not checked against
null pointer.

Finally, there are plain C code, that uses malloc and similar functions. If
the result is not checked, assert statements are added.

Differential Revision: https://reviews.llvm.org/D43010

llvm-svn: 325224
2018-02-15 09:20:26 +00:00
Hans Wennborg 8276556b62 Defeat a GCC -Wunused-result warning
It was warning like:

../llvm-project/llvm/lib/Support/ErrorHandling.cpp:172:51: warning:
ignoring return value of ‘ssize_t write(int, const void*, size_t)’,
         declared with attribute warn_unused_result [-Wunused-result]
            (void)::write(2, OOMMessage, strlen(OOMMessage));

Work around the warning by storing the return value in a variable and
casting that to void instead. We already did this for the other write()
call in this file.

llvm-svn: 308483
2017-07-19 15:03:38 +00:00
Reid Kleckner 1c0f6ed45a Put std::mutex usage behind #ifdefs to pacify the sanitizer buildbot
llvm-svn: 307925
2017-07-13 16:56:24 +00:00
Reid Kleckner 5ae1bfe813 Use std::mutex to avoid memory allocation after OOM
ManagedStatic<sys::Mutex> would lazilly allocate a sys::Mutex to lock
when reporting an OOM, which is a bad idea.

The three STL implementations that I know of use pthread_mutex_lock and
EnterCriticalSection to implement std::mutex. I'm pretty sure that
neither of those allocate heap memory.

It seems that we unconditionally use std::mutex without testing
LLVM_ENABLE_THREADS elsewhere in the codebase, so this should be
portable.

llvm-svn: 307827
2017-07-12 18:23:06 +00:00
Reid Kleckner ada8c398d0 [Support] - Add bad alloc error handler for handling allocation malfunctions
Summary:
Patch by Klaus Kretzschmar

We would like to introduce a new type of llvm error handler for handling
bad alloc fault situations.  LLVM already provides a fatal error handler
for serious non-recoverable error situations which by default writes
some error information to stderr and calls exit(1) at the end (functions
are marked as 'noreturn').

For long running processes (e.g. a server application), exiting the
process is not an acceptable option, especially not when the system is
in a temporary resource bottleneck with a good chance to recover from
this fault situation. In such a situation you would rather throw an
exception to stop the current compilation and try to overcome the
resource bottleneck. The user should be aware of the problem of throwing
an exception in bad alloc situations, e.g. you must not do any
allocations in the unwind chain. This is especially true when adding
exceptions in existing unfamiliar code (as already stated in the comment
of the current fatal error handler)

So the new handler can also be used to distinguish from general fatal
error situations where recovering is no option.  It should be used in
cases where a clean unwind after the allocation is guaranteed.

This patch contains:
- A report_bad_alloc function which calls a user defined bad alloc
  error handler. If no user handler is registered the
  report_fatal_error function is called. This function is not marked as
  'noreturn'.
- A install/restore_bad_alloc_error_handler to install/restore the bad
  alloc handler.
- An example (in Mutex.cpp) where the report_bad_alloc function is
  called in case of a malloc returns a nullptr.

If this patch gets accepted we would create similar patches to fix
corresponding malloc/calloc usages in the llvm code.

Reviewers: chandlerc, greened, baldrick, rnk

Reviewed By: rnk

Subscribers: llvm-commits, MatzeB

Differential Revision: https://reviews.llvm.org/D34753

llvm-svn: 307673
2017-07-11 16:45:30 +00:00
Lang Hames e7aad357a9 [Support] Make all Errors convertible to std::error_code.
This is a temporary crutch to enable code that currently uses std::error_code
to be incrementally moved over to Error. Requiring all Error instances be
convertible enables clients to call errorToErrorCode on any error (not just
ECErrors created by conversion *from* an error_code).

This patch also moves code for Error from ErrorHandling.cpp into a new
Error.cpp file.

llvm-svn: 264221
2016-03-23 23:57:28 +00:00
Lang Hames f7f6d3e93f [Support] Add the 'Error' class for structured error handling.
This patch introduces the Error classs for lightweight, structured,
recoverable error handling. It includes utilities for creating, manipulating
and handling errors. The scheme is similar to exceptions, in that errors are
described with user-defined types. Unlike exceptions however, errors are
represented as ordinary return types in the API (similar to the way
std::error_code is used).

For usage notes see the LLVM programmer's manual, and the Error.h header.
Usage examples can be found in unittests/Support/ErrorTest.cpp.

Many thanks to David Blaikie, Mehdi Amini, Kevin Enderby and others on the
llvm-dev and llvm-commits lists for lots of discussion and review.

llvm-svn: 263609
2016-03-16 01:02:46 +00:00
Eric Christopher a6b96004b5 Reorganize the C API headers to improve build times.
Type specific declarations have been moved to Type.h and error handling
routines have been moved to ErrorHandling.h. Both are included in Core.h
so nothing should change for projects directly including the headers,
but transitive dependencies may be affected.

llvm-svn: 255965
2015-12-18 01:46:52 +00:00
Chandler Carruth d9903888d9 [cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974
2015-01-14 11:23:27 +00:00
Chris Bieneman 489d1dce3f Converting the ErrorHandlerMutex to a ManagedStatic to avoid the static constructor and destructor.
llvm-svn: 219028
2014-10-03 22:03:12 +00:00
Rafael Espindola 58cb745f31 Merge lib/Support/WindowsError.cpp into ib/Support/ErrorHandling.cpp.
The OSX ranlib warns on files with no symbols, and lib/Support/WindowsError.cpp
was empty when building on non-windows.

llvm-svn: 211118
2014-06-17 18:06:45 +00:00
Zachary Turner 586fd74c30 Make the error-handling functions thread-safe.
Prior to this change, error handling functions must be installed
and removed only inside of an llvm_[start/stop]_multithreading
pair.  This change allows error handling functions to be installed
any time, and from any thread.

Reviewed by: chandlerc

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

llvm-svn: 210937
2014-06-13 21:20:44 +00:00
Zachary Turner 6610b99cb5 Revert "Remove support for runtime multi-threading."
This reverts revision r210600.

llvm-svn: 210603
2014-06-10 23:15:43 +00:00
Zachary Turner f6054ca18c Remove support for runtime multi-threading.
This patch removes the functions llvm_start_multithreaded() and
llvm_stop_multithreaded(), and changes llvm_is_multithreaded()
to return a constant value based on the value of the compile-time
definition LLVM_ENABLE_THREADS.

Previously, it was possible to have compile-time support for
threads on, and runtime support for threads off, in which case
certain mutexes were not allocated or ever acquired.  Now, if the
build is created with threads enabled, mutexes are always acquired.

A test before/after patch of compiling a very large TU showed no
noticeable performance impact of this change.

Reviewers: rnk

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

llvm-svn: 210600
2014-06-10 23:01:20 +00:00
Craig Topper c10719f55d [C++11] Make use of 'nullptr' in the Support library.
llvm-svn: 205697
2014-04-07 04:17:22 +00:00
Alp Toker 17d4e98e73 Roll back the ConstStringRef change for now
There are a couple of interesting things here that we want to check over
(particularly the expecting asserts in StringRef) and get right for general use
in ADT so hold back on this one. For clang we have a workable templated
solution to use in the meanwhile.

This reverts commit r200187.

llvm-svn: 200194
2014-01-27 05:24:39 +00:00
Alp Toker 042f41b047 StringRef: Extend constexpr capabilities and introduce ConstStringRef
(1) Add llvm_expect(), an asserting macro that can be evaluated as a constexpr
    expression as well as a runtime assert or compiler hint in release builds. This
    technique can be used to construct functions that are both unevaluated and
    compiled depending on usage.

(2) Update StringRef using llvm_expect() to preserve runtime assertions while
    extending the same checks to static asserts in C++11 builds that support the
    feature.

(3) Introduce ConstStringRef, a strong subclass of StringRef that references
    compile-time constant strings. It's convertible to, but not from, ordinary
    StringRef and thus can be used to add compile-time safety to various interfaces
    in LLVM and clang that only accept fixed inputs such as diagnostic format
    strings that tend to get misused.

llvm-svn: 200187
2014-01-27 04:07:17 +00:00
Chandler Carruth 8a8cd2bab9 Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.

llvm-svn: 198685
2014-01-07 11:48:04 +00:00
Alexey Samsonov 49109a279c Revert r194865 and r194874.
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
  Base *foo = new Child();
  delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.

llvm-svn: 194997
2013-11-18 09:31:53 +00:00
Juergen Ributzka dbedae89b9 [weak vtables] Remove a bunch of weak vtables
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.

Differential Revision: http://llvm-reviews.chandlerc.com/D2068

Reviewed by Andy

llvm-svn: 194865
2013-11-15 22:34:48 +00:00
Alp Toker acf49f31b6 Fix the -Werror -Wpedantic clang selfhost build
This is a stopgap fix for cast warnings introduced in r192864.

A proper fix should be investigated by the author when possible.

llvm-svn: 193160
2013-10-22 12:30:55 +00:00
Filip Pizlo a535b14157 Expose install_fatal_error_handler() through the C API.
I expose the API with some caveats:

- The C++ API involves a traditional void* opaque pointer for the fatal 
error callback.  The C API doesn’t do this.  I don’t think that the void* 
opaque pointer makes any sense since this is a global callback - there will 
only be one of them.  So if you need to pass some data to your callback, 
just put it in a global variable.

- The bindings will ignore the gen_crash_diag boolean.  I ignore it because 
(1) I don’t know what it does, (2) it’s not documented AFAIK, and (3) I 
couldn’t imagine any use for it.  I made the gut call that it probably 
wasn’t important enough to expose through the C API.

llvm-svn: 192864
2013-10-17 01:38:28 +00:00
Reid Kleckner 5f4535b974 [Support] Fix some warnings when self-hosting clang on Windows
llvm-svn: 186413
2013-07-16 14:04:08 +00:00
Chad Rosier 583b4d3961 Add a boolean parameter to the llvm::report_fatal_error() function to indicated
if crash diagnostics should be generated.  By default this is enabled.
Part of rdar://13296693

llvm-svn: 178161
2013-03-27 18:27:54 +00:00
Chandler Carruth ed0881b2a6 Use the new script to sort the includes of every file under lib.
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
2012-12-03 16:50:05 +00:00
Chad Rosier 379574fd20 Revert 167755/167760. We don't want to emit crash diagnostics on command-line syntax errors.
llvm-svn: 167849
2012-11-13 16:42:19 +00:00
Chad Rosier 2b2b38d336 Revert r167620; this can be implemented using an existing CL option.
llvm-svn: 167755
2012-11-12 21:32:44 +00:00
Jay Foad 72e705ed94 Like the coding standards say, do not use "using namespace std".
llvm-svn: 130054
2011-04-23 09:06:00 +00:00
Michael J. Spencer 447762da85 Merge System into Support.
llvm-svn: 120298
2010-11-29 18:16:10 +00:00
Daniel Dunbar 2ed3fe08e9 report_fatal_error: Simplify a possible ambiguity.
llvm-svn: 118972
2010-11-13 02:48:51 +00:00
Duncan Sands c8ba8d2085 Some versions of gcc still warn about "ignoring return value ... declared
with attribute warn_unused_result" here - suppress the warning harder.

llvm-svn: 114072
2010-09-16 08:20:49 +00:00
Dan Gohman 3490ff4002 Tidy.
llvm-svn: 111432
2010-08-18 22:04:43 +00:00
Chris Lattner 7aa9eb16fd include config.h to get config params, hopefully unbreaking mingw builder.
llvm-svn: 111325
2010-08-17 23:22:10 +00:00
Chris Lattner 6217082dc3 report_fatal_error can't use errs(), because errs() can call
into report_fatal_error.  Just blast the string to stderr with write(2)
and hope for the best!  Part of rdar://8318441

llvm-svn: 111320
2010-08-17 23:03:53 +00:00
Daniel Dunbar 401d4c9341 Run interrupt routines as part of report_fatal_error, since we are failing
ungracefully.

llvm-svn: 103334
2010-05-08 02:10:36 +00:00
Chris Lattner 59c5753174 rename llvm_install_error_handler -> install_fatal_error_handler
and friends.

llvm-svn: 100717
2010-04-07 23:12:29 +00:00
Chris Lattner 2104b8d36e rename llvm::llvm_report_error -> llvm::report_fatal_error
llvm-svn: 100709
2010-04-07 22:58:41 +00:00
Dan Gohman b452d4e9e4 Fix minor style issues.
llvm-svn: 99414
2010-03-24 19:38:02 +00:00
David Greene 80604d5f09 Change errs() to dbgs().
llvm-svn: 92637
2010-01-05 01:28:29 +00:00
Dan Gohman e392e6236d Add a comment explaining why llvm_unreachable_internal doesn't call
the ErrorHandler callback.

llvm-svn: 79541
2009-08-20 17:15:19 +00:00
Dan Gohman 1432ef864e This void is implicit in C++.
llvm-svn: 78848
2009-08-12 22:10:57 +00:00
Daniel Dunbar 1bf60c257c Add support for a user supplied pointer argument to llvm_install_error_handler.
llvm-svn: 78553
2009-08-10 03:36:26 +00:00
Daniel Dunbar cd51ea510a Allow llvm_report_error to accept a Twine.
llvm-svn: 76961
2009-07-24 07:58:10 +00:00
Torok Edwin fbcc663cbf llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable.
This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").

llvm-svn: 75640
2009-07-14 16:55:14 +00:00
Torok Edwin 1ab40bef8d After converting assert(0) to LLVM_UNREACHABLE we lost file/line location.
Fix by making the LLVM_UNREACHABLE pass __FILE__ and __LINE__ to
llvm_unreachable.

llvm-svn: 75631
2009-07-14 12:49:22 +00:00
Torok Edwin 56d0659726 assert(0) -> LLVM_UNREACHABLE.
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.

llvm-svn: 75379
2009-07-11 20:10:48 +00:00