When compiling for Darwin, sigset is not initialized.
When -Werror,-Wuninitialized-const-reference are enabled we see the
error:
asan_interceptors.cpp:260:38: error: variable 'sigset' is uninitialized
when passed as a const reference argument here
[-Werror,-Wuninitialized-const-reference]
This fixes the error
This patch fixes:
compiler-rt/lib/builtins/int_to_fp_impl.inc:36:10: error: expression
is not an integer constant expression; folding it to a constant is a
GNU extension [-Werror,-Wgnu-folding-constant]
Deploying #67766 to a large internal codebase uncovers many bugs (many
are
probably benign but need cleaning up). There are also issues in
high-profile
open-source projects like v8. Add a cl::opt to disable builtin
instrumentation
for -fsanitize=alignment to help large codebase users.
In the long term, this cl::opt option may still be useful to debug
-fsanitize=alignment instrumentation on builtins, so we probably want to
keep it around.
The MVETRUNC operation can perform the same truncate of two vectors, without
requiring lane inserts/extracts from every vector lane. This moves the concat
i1 lowering to use it for v8i1 and v16i1 result types, trading a bit of extra
stack space for less instructions.
This will make it easier to implement new(nothrow) without calling the
throwing version of new when exceptions are disabled. See
https://llvm.org/D150610 for the full discussion.
The current test cases to guard against speculative execution can actually be
safely speculated because the denominator is known to be not 0 or -1, and
isSafeToSpeculativelyExecuteWithOpcode will account for this. This adds some
more test cases and rejigs some existing ones to use an unknown variable
instead.
When MergeFuncs creates a thunk, it does not modify the function in
place, but creates a new one altogether. If type metadata is not
properly forwarded to this new function, LowerTypeTests will be unable
to put this thunk into the dispatch table.
The fix here is to just forward the type metadata to the newly created
functions.
The user of CodeExtractor should be able to specify that
the aggregate argument should be passed as a pointer in zero address
space.
CodeExtractor is used to generate outlined functions required by OpenMP
runtime. The arguments of the outlined functions for OpenMP GPU code
are in 0 address space. 0 address space does not need to be the default
address space for GPU device. That's why there is a need to allow
the user of CodeExtractor to specify, that the allocated aggregate parameter
is passed as pointer in zero address space.
stack-uar.c is flaky (1 in 256 executions) because the random tag
may be zero (https://github.com/llvm/llvm-project/issues/69221).
This patch works around the issue in the same way as deep-recursion.c
(aa4dfd3736),
by falling back to a neighboring object, which must have a different
(non-zero) tag.
This patch also does a minor cleanup of the aforementioned
deep-recursion.c, for consistency with stack-uar.c.
Co-authored-by: Thurston Dang <thurston@google.com>
Use of llvm::Optional was migrated to std::optional. This included a
change in the constructor of ArrayRef.
However, there are still 2 places in the SubtargetEmitter which uses
llvm::None, causing a compile error when emitted.
When the code is built with -mbackchain, it is possible to retrieve the
caller's frame and return addresses. GCC already can do this, add this
support to Clang as well. Use RISCVTargetLowering and GCC's
s390_return_addr_rtx() as inspiration. Add tests based on what GCC is
emitting.
Summary:
We use `malloc` internally in the DeviceRTL to handle data
globalization. If this is undefined it will map to the Nvidia
implementation of `malloc` for NVPTX and return `nullptr` for AMDGPU.
This is somewhat problematic, because when using this as a shared
library it causes us to always extract the GPU libc implementation,
which uses RPC and thus requires an RPC server. Making this `weak`
allows us to implement this internally without worrying about binding to
the GPU `libc` implementation.
This change introduces the bitfield conversion check after fixes to the
test case. The original submission unfortunately did not comprehend
differences in architecture for the diagnostic messages, leading to
unanticipated failures in the arm build bots.
Original PR: https://github.com/llvm/llvm-project/pull/68276
Clang does not check for bitfield assignment widths, while gcc checks
this.
gcc produced a warning like so for it's -Wconversion flag:
```
$ gcc -Wconversion -c test.c
test.c: In function 'foo':
test.c:10:15: warning: conversion from 'int' to 'signed char:7' may
change value [-Wconversion]
10 | vxx.bf = x; // no warning
| ^
```
This change simply adds this check for integral types under the
-Wbitfield-conversion compiler option.
The constant expression engines use a list of note diagnostics to
report back whether an evaluation is a valid constant expression or
not. This requires the engines to generate those note diagnostics, and
that can be expensive in cases where we're converting an APValue to a
string as a streamed argument to the note. If we're going to display
the note, then that expense is warranted. However, there are operations
looking for a yes/no answer to whether something is a constant
expression and won't display the diagnostics at all. Those uses are
paying an expense they shouldn't have to.
Out of line class template declaration specializations aren't created at
the time they have their template arguments checked, so we previously
weren't doing any amount of work to substitute the constraints before
comparison. This resulted in the out of line definition's difference in
'depth' causing the constraints to compare differently.
This patch corrects that. Additionally, it handles ClassTemplateDecl
when collecting template arguments.
Fixes: #61763
Instead of reporting the error directly through the DWARFContext passed
in as an argument, it would be more flexible to have extract return the
error and allow the caller to react appropriately.
This will be useful for using llvm's DWARFHeaderUnit from lldb which may
report header extraction errors through a different mechanism.
If a CMake project doesn't enable the C language, then the CMake FFI and
Terminfo find modules will fail their checks for compilation and
linking.
This commit allows projects to enable only C++ by first checking if a C
compiler is set before testing C source compilation; if not, it checks
whether C++ compilation succeeds.
Fixes#53950
Follow-up to #69295: In `Writer<ELFT>::run`, the symbol passes are
flexible:
they can be placed almost everywhere before `scanRelocations`, with a
constraint
that the `computeIsPreemptible` pass must be invoked for linker-defined
non-local symbols.
Merge copyLocalSymbols and demoteLocalSymbolsInDiscardedSections to
simplify
code:
* Demoting local symbols can be made unconditional, not constrainted to
/DISCARD/ uses due to performance concerns
* `includeInSymtab` can be made faster
* Make symbol passes close to each other
* Decrease data cache misses due to saving an iteration over local
symbols
There is no speedup, likely due to the unconditional `dr->section`
access in `demoteAndCopyLocalSymbols`.
`gc-sections-tls.s` no longer reports an error because the TLS symbol is
converted to an Undefined.
This patch adds a new fn attribute, `optdebug`, that specifies that
optimizations should make decisions that prioritize debug info quality,
potentially at the cost of runtime performance.
This patch does not add any functional changes triggered by this
attribute, only the attribute itself. A subsequent patch will use this
flag to disable the post-RA scheduler.
LLVM detects when ncurses has a separate terminfo library, but linking to it
was broken in lldb since b66339575a9b541e67ce5ad2ba7e88da07cf9305 (LLVM14)
due to a change of variables. This commit fixes that oversight.
The reason I want this is that I am writing my own Python bindings and
would like to use the insertion point from
`PyThreadContextEntry::getDefaultInsertionPoint()` to call C++ functions
that take an `OpBuilder` (I don't need to expose it in Python but it
also seems appropriate). AFAICT, there is currently no way to translate
a `PyInsertionPoint` into an `OpBuilder` because the operation is
inaccessible.
I noticed that `flang-new` cannot link Fortran executables on Solaris since the runtime libs are missing.
This patch fixes this, following `Gnu.cpp`. The `linker-flags.f90` testcase is augmented to test for this,
renaming the `GNU` label to `UNIX` so it can be reused. Also use the current form `--target=` in the tests
and join the `-l` lines in the test for readibility.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
This patch adds some missing documentation for some attributes in
BitCodeFormat, where the integer code mappings for attributes after code
79 were not listed, and in LangRef where the incompatibility between
minsize/optsize and optnone was not mentioned.
Previously, these would set their ArrayRef members to reference their
storage SmallVectors after a copy-on-write (COW) operation. This leads
to a use-after-free if the builder is copied and the original destroyed
(as the new builder would still reference the old SmallVector).
This could easily accidentally occur in code like (annotated):
```c++
// 1. `VectorType::Builder(type)` constructs a new temporary builder
// 2. `.dropDim(0)` updates the temporary builder by reference, and returns a `VectorType::Builder&`
// - Modifying the shape is a COW operation, so `storage` is used, and `shape` updated the reference it
// 3. Assigning the reference to `auto` copies the builder (via the default C++ copy ctor)
// - There's no special handling for `shape` and `storage`, so the new shape points to the old builder's `storage`
auto newType = VectorType::Builder(type).dropDim(0);
// 4. When this line is reached the original temporary builder is destroyed
// - Actually constructing the vector type is now a use-after-free
VectorType newVectorType = VectorType(newType);
```
This is fixed with these changes by using `CopyOnWriteArrayRef<T>`,
which implements the same functionality, but ensures no
dangling references are possible if it's copied.
---
The VectorType::Builder also set the ArrayRef<bool> scalableDims member
to a temporary SmallVector when the provided scalableDims are empty.
This again leads to a use-after-free, and is unnecessary as
VectorType::get already handles being passed an empty scalableDims
array.
These bugs were in-part caught by UBSAN, see:
https://lab.llvm.org/buildbot/#/builders/5/builds/37355
Waterfall loop is overwriting SCC bit of status register. Make sure SCC
bit is saved and restored across.
We need to save/restore only in cases where SCC is live across waterfall
loop.
Co-authored-by: Sirish Pande <sirish.pande@amd.com>
