Commit Graph

14 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
Serge Pavlov 76d8ccee2e Report fatal error in the case of out of memory
This is the second part of recommit of r325224. The previous part was
committed in r325426, which deals with C++ memory allocation. Solution
for C memory allocation involved functions `llvm::malloc` and similar.
This was a fragile solution because it caused ambiguity errors in some
cases. In this commit the new functions have names like `llvm::safe_malloc`.

The relevant part of original comment is below, updated for new function
names.

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.

In some cases memory is allocated by a call to some of 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 for null pointer. To simplify checks, new functions are defined
in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`.
They behave as corresponding standard functions but produce fatal error if
allocation fails. This change replaces the standard functions like 'malloc'
in the cases when the result of the allocation function is not checked
for null pointer.

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

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

llvm-svn: 325551
2018-02-20 05:41:26 +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
Kristof Beyls a11dbf2c90 Remove more name space pollution from .inc files
llvm-svn: 299222
2017-03-31 14:26:44 +00:00
David Blaikie df9515324d PR21202: Memory leak in Windows RWMutexImpl when using SRWLOCK
llvm-svn: 220251
2014-10-21 00:34:39 +00:00
Reid Kleckner d59e2faae1 Rename Windows.h to WindowsSupport.h to avoid ambiguity
llvm-svn: 201258
2014-02-12 21:26:20 +00:00
David Majnemer 7af18578f8 Windows: Don't bother with pinning Kernel32.dll
We don't delay load it so it shouldn't be going anywhere.

llvm-svn: 192561
2013-10-14 00:06:58 +00:00
David Majnemer a5732844a6 Windows: Use GetModuleHandleEx instead of LoadLibrary
We were using an anti-pattern of:
 - LoadLibrary
 - GetProcAddress
 - FreeLibrary

This is problematic because of several reasons:
 - We are holding on to pointers into a library we just unloaded.
 - Calling LoadLibrary results in an increase in the reference count of
   the library in question and any libraries that it depends on and
   so-on and so-forth.  This is none too quick.

Instead, use GetModuleHandleEx with GET_MODULE_HANDLE_EX_FLAG_PIN.  This
is done because because we didn't bring the reference for the library
into existence and therefor shouldn't count on it being around later.

llvm-svn: 192550
2013-10-13 10:34:21 +00:00
David Majnemer 17a44966be Windows: Be more explicit with Win32 APIs
This addresses several issues in a similar vein:
 - Use the Unicode APIs when possible, running nm on clang shows that we
   only use Unicode APIs except for FormatMessage, CreateSemaphore, and
   GetModuleHandle.  AFAICT, the latter two are coming from MinGW and
   not LLVM itself.
 - Make getMainExecutable more resilient.  It previously considered
   return values of zero from ::GetModuleFileNameA to be acceptable.

llvm-svn: 192096
2013-10-07 09:52:36 +00:00
Bill Wendling 2b07965042 Remove tabs.
llvm-svn: 160476
2012-07-19 00:06:06 +00:00
Michael J. Spencer 0084615924 Support/Windows: Add efficent RW mutex on Windows. Patch by Aaron Ballman!
llvm-svn: 141907
2011-10-13 23:10:56 +00:00
Charles Davis 54c9eb6fff Now to chant the magical incantation that will exorcise the System library
from LLVM forever:

grep -lR "llvm/System" * | grep -v .svn | xargs sed -ie 's#llvm/System#llvm/Support#g'

llvm-svn: 120314
2010-11-29 19:44:50 +00:00
Michael J. Spencer 447762da85 Merge System into Support.
llvm-svn: 120298
2010-11-29 18:16:10 +00:00