Wrap `llvm_unreachable` macro in do-while loop

Macros that expand into multiple terms can cause interesting preprocessor hickups depending
on the context they are used in. https://github.com/llvm/ll

Wrap `llvm_unreachable` macro in do-while loop

Macros that expand into multiple terms can cause interesting preprocessor hickups depending
on the context they are used in. https://github.com/llvm/llvm-project/issues/56867 reported
a miscompilation of `llvm_unreachable(msg)` inside a `LLVM_DEBUG({ ... })` block. We were
able to fix it by wrapping the expansion in a `do {} while(false)`.

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

show more ...

Adjust `llvm_unreachable` macro to account for platforms that don't define LLVM_BUILTIN_UNREACHABLE

Post 892c104fb7, LLVM_BUILTIN_UNREACHABLE may not be defined anymore.
Also when LLVM_UNREACHABLE_O

Adjust `llvm_unreachable` macro to account for platforms that don't define LLVM_BUILTIN_UNREACHABLE

Post 892c104fb7, LLVM_BUILTIN_UNREACHABLE may not be defined anymore.
Also when LLVM_UNREACHABLE_OPTIMIZE is OFF, emit LLVM_BUILTIN_UNREACHABLE
after LLVM_BUILTIN_TRAP to ensure that diagnostics are suppressed on
environments where LLVM_BUILTIN_TRAP is not marked as noreturn.

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

show more ...

Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled

This re-lands 6316129e066e after fixing the condition logic.

The new flag seems to not be working yet

Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled

This re-lands 6316129e066e after fixing the condition logic.

The new flag seems to not be working yet on Windows, where the builtin
trap isn't "no return".

Reviewed By: dexonsmith

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

show more ...

Revert "Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled"

This reverts commit 6316129e066e0a252430699f2b41706d4808476c.

This was implemented with inver

Revert "Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled"

This reverts commit 6316129e066e0a252430699f2b41706d4808476c.

This was implemented with inverted logic.

show more ...

Add a cmake flag to turn `llvm_unreachable()` into builtin_trap() when assertions are disabled

Reviewed By: dexonsmith

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

[Support] ErrorHandling.h - Remove report_fatal_error(std::string)

As described on D111049, removing the <string> dependency from error handling removes considerable build overhead, its recommended

[Support] ErrorHandling.h - Remove report_fatal_error(std::string)

As described on D111049, removing the <string> dependency from error handling removes considerable build overhead, its recommended that the report_fatal_error(Twine) variant is used instead.

show more ...

[Support] Change fatal_error_handler_t to take a const char* instead of std::string

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

Excessive use of the <

[Support] Change fatal_error_handler_t to take a const char* instead of std::string

https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html

Excessive use of the <string> header has a massive impact on compile time; its most commonly included via the ErrorHandling.h header, which has to be included in many key headers, impacting many source files that have no need for std::string.

As an initial step toward removing the <string> include from ErrorHandling.h, this patch proposes to update the fatal_error_handler_t handler to just take a raw const char* instead.

The next step will be to remove the report_fatal_error std::string variant, which will involve a lot of cleanup and better use of Twine/StringRef.

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

show more ...

[llvm] Replace LLVM_ATTRIBUTE_NORETURN with C++11 [[noreturn]]

[[noreturn]] can be used since Oct 2016 when the minimum compiler requirement was bumped to GCC 4.8/MSVC 2015.

Note: the definition of

[llvm] Replace LLVM_ATTRIBUTE_NORETURN with C++11 [[noreturn]]

[[noreturn]] can be used since Oct 2016 when the minimum compiler requirement was bumped to GCC 4.8/MSVC 2015.

Note: the definition of LLVM_ATTRIBUTE_NORETURN is kept for now.

show more ...

Improve error handling for SmallVector programming errors

This patch changes errors in `SmallVector::grow` that are independent of
memory capacity to be reported using report_fatal_error or
std::len

Improve error handling for SmallVector programming errors

This patch changes errors in `SmallVector::grow` that are independent of
memory capacity to be reported using report_fatal_error or
std::length_error instead of report_bad_alloc_error, which falsely signals
an OOM.

It also cleans up a few related things:
- makes report_bad_alloc_error to print the failure reason passed
to it.
- fixes the documentation to indicate that report_bad_alloc_error
calls `abort()` not "an assertion"
- uses a consistent name for the size/capacity argument to `grow`
and `grow_pod`

Reviewed By: mehdi_amini, MaskRay

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

show more ...

Add LLVM_ATTRIBUTE_NORETURN to report_bad_alloc_error

Summary:
The attribute just means that there will be no regular return, it still
leaves room for exceptions to be thrown. It is easily verified:

Add LLVM_ATTRIBUTE_NORETURN to report_bad_alloc_error

Summary:
The attribute just means that there will be no regular return, it still
leaves room for exceptions to be thrown. It is easily verified: there
are no direct returns and the last statement is either a throw or a call
to abort.

Having the annotation helps static analyzers with this code from
Support/MemAlloc.h (slightly simplified):

LLVM_ATTRIBUTE_RETURNS_NONNULL inline void *safe_malloc(size_t Sz) {
void *Result = std::malloc(Sz);
if (Result == nullptr)
report_bad_alloc_error("Allocation failed");
return Result;
}

Were report_bad_alloc_error to return regularly, the function would
return nullptr, contradicting the attribute.

Reviewers: rnk, sepavloff, dblaikie, aaron.ballman

Reviewed By: dblaikie, aaron.ballman

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

show more ...

[docs] Fix self-contradictory description of llvm_unreachable

Just two paragraphs above it says:
"If the compiler does not support this [skipping code generation for a particular branch], it will fa

[docs] Fix self-contradictory description of llvm_unreachable

Just two paragraphs above it says:
"If the compiler does not support this [skipping code generation for a particular branch], it will fall back
to the "abort" implementation."

And that actually correctly describes llvm_unreachable implementation.

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

show more ...

Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`"""

This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes.

Previously, since bots turning on EXP

Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`"""

This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes.

Previously, since bots turning on EXPENSIVE_CHECKS are essentially turning on
MachineVerifierPass by default on X86 and the fact that
inline-asm-avx-v-constraint-32bit.ll and inline-asm-avx512vl-v-constraint-32bit.ll
are not expected to generate functioning machine code, this would go
down to `report_fatal_error` in MachineVerifierPass. Here passing
`-verify-machineinstrs=0` to make the intent explicit.

show more ...

Revert "Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`""""

This reverts commit bb51d243308dbcc9a8c73180ae7b9e47b98e68fb.

Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`"""

This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes.

On bots llvm-clang-x86_64-expensive-c

Revert "Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`"""

This reverts commit 80a34ae31125aa46dcad47162ba45b152aed968d with fixes.

On bots llvm-clang-x86_64-expensive-checks-ubuntu and
llvm-clang-x86_64-expensive-checks-debian only,
llc returns 0 for these two tests unexpectedly. I tweaked the RUN line a little
bit in the hope that LIT is the culprit since this change is not in the
codepath these tests are testing.
llvm\test\CodeGen\X86\inline-asm-avx-v-constraint-32bit.ll
llvm\test\CodeGen\X86\inline-asm-avx512vl-v-constraint-32bit.ll

show more ...

Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`""

This reverts commit rGcd5b308b828e, rGcd5b308b828e, rG8cedf0e2994c.

There are issues to be investigated for polly bots

Revert "Reland "[Support] make report_fatal_error `abort` instead of `exit`""

This reverts commit rGcd5b308b828e, rGcd5b308b828e, rG8cedf0e2994c.

There are issues to be investigated for polly bots and bots turning on
EXPENSIVE_CHECKS.

show more ...

Reland "[Support] make report_fatal_error `abort` instead of `exit`"

Summary:
Reland D67847 after D73742 is committed. Replace `sys::Process::Exit(1)`
with `abort` in `report_fatal_error`.

After th

Reland "[Support] make report_fatal_error `abort` instead of `exit`"

Summary:
Reland D67847 after D73742 is committed. Replace `sys::Process::Exit(1)`
with `abort` in `report_fatal_error`.

After this patch, for tools turning on `CrashRecoveryContext`,
crash handler installed by `CrashRecoveryContext` is called unless
they installed a non-returning handler using `llvm::install_fatal_error_handler`
like `cc1_main` currently does.

Reviewers: rnk, MaskRay, aganea, hans, espindola, jhenderson

Subscribers: jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, rupprecht, jocewei, jsji, Jim, dmgreen, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, kerbowa, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

Revert "[Support] make report_fatal_error `abort` instead of `exit`"

This reverts commit 647c3f4e47de8a850ffcaa897db68702d8d2459a.

Got bots failure from sanitizer-windows and maybe others.

[Support] make report_fatal_error `abort` instead of `exit`

Summary:
This patch could be treated as a rebase of D33960. It also fixes PR35547.
A fix for `llvm/test/Other/close-stderr.ll` is proposed

[Support] make report_fatal_error `abort` instead of `exit`

Summary:
This patch could be treated as a rebase of D33960. It also fixes PR35547.
A fix for `llvm/test/Other/close-stderr.ll` is proposed in D68164. Seems
the consensus is that the test is passing by chance and I'm not
sure how important it is for us. So it is removed like in D33960 for now.
The rest of the test fixes are just adding `--crash` flag to `not` tool.

** The reason it fixes PR35547 is

`exit` does cleanup including calling class destructor whereas `abort`
does not do any cleanup. In multithreading environment such as ThinLTO or JIT,
threads may share states which mostly are ManagedStatic<>. If faulting thread
tearing down a class when another thread is using it, there are chances of
memory corruption. This is bad 1. It will stop error reporting like pretty
stack printer; 2. The memory corruption is distracting and nondeterministic in
terms of error message, and corruption type (depending one the timing, it
could be double free, heap free after use, etc.).

Reviewers: rnk, chandlerc, zturner, sepavloff, MaskRay, espindola

Reviewed By: rnk, MaskRay

Subscribers: wuzish, jholewinski, qcolombet, dschuff, jyknight, emaste, sdardis, nemanjai, jvesely, nhaehnle, sbc100, arichardson, jgravelle-google, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, lenary, s.egerton, pzheng, cfe-commits, MaskRay, filcab, davide, MatzeB, mehdi_amini, hiraditya, steven_wu, dexonsmith, rupprecht, seiya, llvm-commits

Tags: #llvm, #clang

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

show more ...

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 ne

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

show more ...

[Support] Fix line width to 80

Test commit

llvm-svn: 346348

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 memo

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

show more ...

Revert r325224 "Report fatal error in the case of out of memory"

It caused fails on some buildbots.

llvm-svn: 325227

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

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

show more ...

test commit

llvm-svn: 322844

[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 f

[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

show more ...