If llvm-readobj is built with a 32 bit time_t, it can't print such
timestamps correctly.
(cherry picked from commit 0bf4ff29816c0eead99ba576a2df2e3c4d214b1f)
This adds support for marking arbitrary general purpose registers -
except for those with special purpose (G0, I6-I7, O6-O7) - as reserved,
as needed by some software like the Linux kernel.
(cherry picked from commit c2f9885a8aa3a820eefdacccf3fcc6b9d87e3284)
The SOURCE_DATE_EPOCH environment variable can be set in order to get
reproducible build.
When linking PE/COFF modules with LLD, the timestamp field is set to the
current time, unless either the /timestamp: or /Brepro option is set. If
neither of them is set, check the SOURCE_DATE_EPOCH variable, before
resorting to using the actual current date and time.
See https://reproducible-builds.org/docs/source-date-epoch/ for reference
on the use of this variable.
(cherry picked from commit 0df8aed6c30f08ded526038a6bbb4daf113a31c1)
-DLIBCXX_ENABLE_UNICODE=OFF or -D_LIBCPP_HAS_NO_UNICODE doesn't build
without this change.
(cherry picked from commit 30cd1838dc334775f7a29f57b581f2bdda3f0ea1)
Fixes#79718. Fixes#71178.
The same instructions may exist in an iteration. We cannot immediately
delete instructions in `ErasedInstrs`.
(cherry picked from commit 95b14da678f4670283240ef4cf60f3a39bed97b4)
OpFlag and WrapperKind should be chosen consistently with each other in
regards to PIC, otherwise we hit asserts later on.
Broken by c04a05d8.
Fixes#80831.
(cherry picked from commit 5a83bccb35d6b0e6914b52af6db067aa01dd3efb)
Commit d813af73f7 addressed a regression introduced by commit
3791b3fca6
but caused `clang-format -dump-config` to "hang".
This patch reverts changes to ClangFormat.cpp by both commits and
reworks the cleanup.
Fixes#80621.
(cherry picked from commit 8f6e13e6da84510c8321717860fd506e12118514)
Libunwind supports FP64 and FP32 modes, but not FPXX. The reason is
that, FP64 and FP32 have different way to save/restore FPRs. If
libunwind is built as FPXX, we have no idea which one should we use.
It's not due to the code bug, but rather the nature of FPXX.
FPXX is an ABI which uses only a common subset of FR=1(FP64) and FR=0
(FP32).
So that FPXX binaries can link with both FP64 and FP32 ones, aka.
FPXX + FP32 -> FP32
FPXX + FP64 -> FP64
While for libunwind, we should save/restore all of FPRs. If we use FPXX,
we can only save/restore a common subset of FPRs, instead of superset.
If libunwind is built as FP64, it will interoperatable with FPXX/FP64
APPs, and if it is built as FP32, it will interoperatable with
FP32/FPXX. Currently most of O32 APPs are FPXX or FP64, while few are
FP32.
So if the compiler is FPXX, which is the default value of most
toolchain, let's switch it to FP64.
Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com>
(cherry picked from commit 4520b478d2512b0f39764e0464dcb4cb961845b5)
C23 has `bool`, but logical operators still return int. Check that
we're not in C to avoid false-positive -Wconstant-logical-operand.
Fixes https://github.com/llvm/llvm-project/issues/64356
(cherry picked from commit a18e92d020b895b712175a3b13a3d021608115a7)
Fix#79283: `test/dfsan/custom.cpp` has undefined symbol linker errors
on glibc 2.38 due to lack of wrappers for `__isoc23_strtol` and
`__isoc23_scanf` family functions.
Implement these wrappers as aliases to existing wrappers, similar to
https://reviews.llvm.org/D158943 for other sanitizers.
`strtol` in a user program, whether or not `_ISOC2X_SOURCE` is defined,
uses the C23 semantics (`strtol("0b1", 0, 0)` => 1), when
`libclang_rt.dfsan.a` is built on glibc 2.38+.
(cherry picked from commit 648560062af8deb4e6478130deb1dd8fa62929a8)
The TargetGuard fields for 'svldr[_vnum]_za' and 'svstr[_vnum]_za' were
incorrectly set to `+sve` instead of `+sme`. This means that compiling
code that uses these intrinsics requires compiling for both `+sve` as
well as `+sme`.
This PR also fixes the target guards for the `svadd` and `svsub`
builtins that are enabled under `+sme2,+sme-i16i64` and
`+sme2,+sme-f64f64`, as it initially did the following:
```
let TargetGuard = "+sme2" in {
let TargetGuard = "+sme-i16i64" in {
// Builtins defined here will be predicated only by
// '+sme-i16i64', and not '+sme2,+sme-i16i64'.
}
}
```
This PR also removes `-target-feature +sve` from all the SME tests, to
ensure that the SME features are sufficient to build the tests.
(cherry picked from commit 3d186a77cf1aa979014a6443cb423a633c167d9f)
This crash is basically caused by calling
`ASTContext::getRawCommentForDeclNoCacheImp` with its input arguments
`RepresentativeLocForDecl` and `CommentsInTheFile` refering to different
files. A reduced reproducer is provided in this patch.
After the source locations for instantiations of funtion template are
corrected in the commit 256a0b298c, the
variable `CommitsInThisFile` in the function
`ASTContext::attachCommentsToJustParsedDecls` would refer to the source
file rather than the header file for implicit function template
instantiation. Therefore, in the first loop in
`ASTContext::attachCommentsToJustParsedDecls`, `D` should also be
adjusted for relevant scenarios like the second loop.
Fixes#67979Fixes#68524Fixes#70550
(cherry picked from commit 5f4ee5a2dfa97fe32ee62d1d67aa1413d5a059e6)
There is more space available on /mnt (~56G) than on / (~30G), and we
are starting to see some of the CI jobs run out of disk space on Linux.
(cherry picked from commit 1a6426067fb33a8a789978f6e229108787a041be)
This was broken by d25022bb689b9bf48a24c0ae6c29c1d3c2f32823, which
caused the workflow to pass an empty string to ninja as the target. The
'all' target is probably not the right target for these tests, but this
is what the behavior was before
d25022bb689b9bf48a24c0ae6c29c1d3c2f32823.
(cherry picked from commit 792d928e15aa30c8b686eff465598ceea0b03891)
This action is really just a wrapper around cmake and ninja. It doesn't
add any value to the builds, and I don't think we need it now that there
are reusable workflows.
(cherry picked from commit d25022bb689b9bf48a24c0ae6c29c1d3c2f32823)
a freebsd dev member reported a symbol conflict and intercepting this
had little value anyway.
(cherry picked from commit 16a1ef86cbc5e6c829919ec6c73325413b0cd21b)
Close https://github.com/llvm/llvm-project/issues/79240
Cite the comment from @mizvekov in
//github.com/llvm/llvm-project/issues/79240:
> There are two kinds of bugs / issues relevant here:
>
> Clang bugs that this change hides
> Here we can add a Frontend flag that disables the GMF ODR check, just
> so
> we can keep tracking, testing and fixing these issues.
> The Driver would just always pass that flag.
> We could add that flag in this current issue.
> Bugs in user code:
> I don't think it's worth adding a corresponding Driver flag for
> controlling the above Frontend flag, since we intend it's behavior to
> become default as we fix the problems, and users interested in testing
> the more strict behavior can just use the Frontend flag directly.
This patch follows the suggestion:
- Introduce the CC1 flag `-fskip-odr-check-in-gmf` which is by default
off, so that the every existing test will still be tested with checking
ODR violations.
- Passing `-fskip-odr-check-in-gmf` in the driver to keep the behavior
we intended.
- Edit the document to tell the users who are still interested in more
strict checks can use `-Xclang -fno-skip-odr-check-in-gmf` to get the
existing behavior.
Close https://github.com/llvm/llvm-project/issues/79240.
See the linked issue for details. Given the frequency of issue reporting
about false positive ODR checks (I received private issue reports too),
I'd like to backport this to 18.x too.
Documents support for Load-Acquire RCpc instructions v3 (rcpc3) as well
as Memory Copy and Memory Set Acceleration instructions (mops) when
targeting AArch64.
Previously when fixing ambiguous lookup diagnostics in
cc1b6668c5 The change refactored
`LookupResult` to split out diagnosing access and ambiguous lookups. The
call to `getSema().CheckLookupAccess(...)` should have guarded by a
check for isAmbiguous(). This change adds that guard.
Fixes: https://github.com/llvm/llvm-project/issues/80435
(cherry picked from commit a7bc9cb6ffa91ff0ebabc45c0c7263c7c2c3a4de)
This change saves memory by providing the allocator more freedom to
allocate the most
efficient size class by dropping the alignment requirements for
std::string's
pointer from 16 to 8. This changes the output of std::string::max_size,
which makes it ABI breaking.
That said, the discussion concluded that we don't care about this ABI
break. and would like this change enabled universally.
The ABI break isn't one of layout or "class size", but rather the value
of "max_size()" changes, which in turn changes whether `std::bad_alloc`
or `std::length_error` is thrown for large allocations.
This change is the child of PR #68807, which enabled the change behind
an ABI flag.
Currently, the way that recomputeLiveIns works is that it will recompute
the livein registers for that MachineBasicBlock but it matters what
order you call recomputeLiveIn which can result in incorrect register
allocations down the line.
Now we do not recompute the entire CFG but we do ensure that the newly
added MBB do reach convergence. This fixes a register allocation bug
introduced in AArch64 stack probing.
(cherry picked from commit ff4636a4ab00b633c15eb3942c26126ceb2662e6)
Currently when interleaving vector calls with linear arguments,
the Part is ignored and all vector calls use the initial value
from the first lane of the current iteration.
Fix this to extract from the correct part of the linear vector.
(cherry picked from commit d4c01714239e80d21e441c3886749fc56b743f81)
Change AfterPlacementOperator to a boolean and deprecate SBPO_Never,
which meant never inserting a space except when after new/delete.
Fixes#78892.
(cherry picked from commit 908fd09a13b2e89a52282478544f7f70cf0a887f)
The result of umin may be poison and in that case the added constraints
are not be valid in contexts where poison doesn't cause UB. Only queue
facts for min/max intrinsics if the result is guaranteed to not be
poison.
This could be improved in the future, by only adding the fact when
solving conditions using the result value.
Fixes https://github.com/llvm/llvm-project/issues/78621.
(cherry picked from commit 3d91d9613e294b242d853039209b40a0cb7853f2)
With a690e86 we added -mcpu/mtune=native support to handle the Microsoft
Azure Cobalt 100 CPU as a Neoverse N2. This patch adds a CPU alias in
TargetParser to maintain compatibility with GCC.
(cherry picked from commit ae8005ffb6cd18900de8ed5a86f60a4a16975471)
FastISel may create a redundant BGTZ terminal which fallthroughes.
```
BGTZ %2:gpr32, %bb.1, implicit-def $at
bb.1.bb1:
; predecessors: %bb.0
```
The `!I->isBarrier()` check in
MipsAsmPrinter::isBlockOnlyReachableByFallthrough
will incorrectly not print a label, leading to a `Undefined temporary
symbol `
error when we try assembling the output assembly file. See the updated
`Fast-ISel/pr40325.ll` and
https://github.com/rust-lang/rust/issues/108835
In addition, the `SwitchInst` condition is too conservative and prints
many unneeded labels (see the updated tests).
Just use the generic isBlockOnlyReachableByFallthrough, updated by
commit 1995b9fead for SPARC, which also
handles MIPS.
(cherry picked from commit 6b2fd7aed66d592738f26c76caa8fff95e168598)
In https://github.com/llvm/llvm-project/pull/76873 a warning was added
when the macros INFINITY and NAN are used in binary expressions when
-menable-no-nans or -menable-no-infs are used. If the user uses an
option that nullifies these two options, the warning will still be
generated. This patch adds an additional information to the warning
comment to let the user know about this. It also suppresses the warning
when #ifdef INFINITY, #ifdef NAN, #ifdef NAN or #ifndef NAN are used in
the code.
(cherry picked from commit 62c352e13c145b5606ace88ecbe9164ff011b5cf)
A recent comment modified the job to only run on the main branch, but
the formatting was slightly off, causing the job to not run. This patch
fixes the formatting so the job will run as expected.
(cherry picked from commit 4b34558f43121df9b863ff2492f74fb2e65a5af1)
Modifying a cherry-picked patch to fix code formatting issues can be
risky, so we don't typically do this. Therefore, it's not necessary to
run this job on the release branches.
(cherry picked from commit 2193c95e2459887e7e6e4f9f4aacf9252e99858f)
The assertion in #80597 failed when we were trying to compute known bits
of a value in an unreachable BB.
859b09da08/llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp (L749-L810)
In this case, `SignBits` is 30 (deduced from instr info), but `Known` is
`10000101010111010011110101000?0?00000000000000000000000000000000`
(deduced from dom cond). Setting high bits of `lshr Known, 1` will lead
to conflict.
This patch masks out high bits of `Known.Zero` to address this problem.
Fixes#80597.
(cherry picked from commit cb8d83a77c25e529f58eba17bb1ec76069a04e90)
Background: BPI stores a collection of edge branch-probabilities, and
also a set of Callback value-handles for the blocks in the
edge-collection. When a block is deleted, BPI's eraseBlock method is
called to clear the edge-collection of references to that block, to
avoid dangling pointers.
However, when move-constructing or assigning a BPI object, the
edge-collection gets moved, but the value-handles are discarded. This
can lead to to stale entries in the edge-collection when blocks are
deleted without the callback -- not normally a problem, but if a new
block is allocated with the same address as an old block, spurious
branch probabilities will be recorded about it. The fix is to transfer
the handles from the source BPI object.
This was exposed by an unrelated debug-info change, it probably just
shifted around allocation orders to expose this. Detected as
nondeterminism and reduced by Zequan Wu:
f1b0a54451 (commitcomment-136737090)
(No test because IMHO testing for a behaviour that varies with memory
allocators is likely futile; I can add the reproducer with a CHECK for
the relevant branch weights if it's desired though)
(cherry picked from commit 604a6c409e8473b212952b8633d92bbdb22a45c9)
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a
CMake project to use for generating the profile data. For example, to
use the llvm-test-suite to generate profile data you would do:
$ cmake -G Ninja -B build -S llvm -C <path to
source>/clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR=<path to llvm-test-suite>
\
-DBOOTSTRAP_CLANG_PGO_TRAINING_DEPS=runtimes
Note that the CLANG_PERF_TRAINING_DEPS has been renamed to
CLANG_PGO_TRAINING_DEPS.
---------
Co-authored-by: Petr Hosek <phosek@google.com>
(cherry picked from commit dd0356d741aefa25ece973d6cc4b55dcb73b84b4)
This enables IR expansion for i128 divisions. The vector case is still
broken because ExpandLargeDivRem doesn't try to handle them.
Fixes: SWDEV-426193
(cherry picked from commit a5d206df792b61a0b6c5ac44343a97696fc6071d)
As of 4d20cfcf4e, `__bit_reference`
contains a template `__fill_n` with a bool `_FillValue` parameter.
Unfortunately there is a relatively widely used piece of scientific
software called NetCDF, which exposes a (C) macro `_FillValue` in its
public headers.
When building the NetCDF C++ bindings, this quickly leads to compilation
errors when the macro interferes with the template in `__bit_reference`.
Rename the parameter to `_FillVal` to avoid the conflict.
(cherry picked from commit 1ec252298925de50b27930c557ba9de3cc397afe)
We noticed that some feature-test macros were not conditional on
configuration flags like _LIBCPP_HAS_NO_FILESYSTEM. As a result, code
attempting to use FTMs would not work as intended.
This patch adds conditionals for a few feature-test macros, but more
issues may exist.
rdar://122020466
(cherry picked from commit f2c84211d2834c73ff874389c6bb47b1c76d391a)
