Emit a 4-byte alignment after the .arm directive and a 2-byte alignment
after the .thumb directive. The new behavior matches GNU assembler.

Fixes #53386

Reviewed By: MaskRay

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

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

This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change indended.

Depends on D151853.

Reviewed By: benlangmuir

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

DNBGetDeploymentInfo was calling GetPlatformString w/o checking that
the load command it was processing actually provided a platform string.
That caused a bunch of worrisome looking error messages in the debugserver
log output.

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

Add some more tests of what exceptions we accept and don't accept.

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

This reverts commit 731f9ac6.

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

Now that we've converted libcxxabi and llvm Demangle to use
std::string_view, this code no longer has any users. Bye bye!

Reviewed By: #libc_abi, phosek, MaskRay

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

This mimics the `ModuleMap` API and enables D151854, where the `AllowCreation = true` function needs `FileEntryRef` but `AllowCreation = false` functions is happy with plain `FileEntry`. No functional change intended.

Reviewed By: benlangmuir

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

This patch removes path hackery from `ModuleMapCallbacks` by adopting `FileEntryRef`. No functional change intended.

Reviewed By: benlangmuir

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

On llvm.org and all downstream forks that I'm aware of, SignalCodes are
always created from C string literals. They are never compared to
anything so they take up space in the ConstString StringPool for no
tangible benefit.

I've changed the type here to `const llvm::StringLiteral` instead of
using a `StringRef` or a `const char *` to express intent -- These
strings come from constant data whose lifetime is directly tied to that
of the running process (and are thus safe to store).

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

This reverts commit 0a762ec1.

Some CPUs enable fp64 by default (such as cortex-m7). When specifying a
single-precision fpu with them like -mfpu=fpv5-sp-d16, the fp64 feature will
be disabled, but fpreg64 will not. We need to disable them both correctly under
clang in order for the backend to be able to use the reliably. In the meantime
this reverts 0a762ec1 until that issue is fixed.

D144654 made it so that we warn on any defining or undefining of
builtin macros. However the C and C++ standards only forbid the
defining or undefining of macros defined in the language standard
itself, but clang defines more macros than those and warning on those
may not be helpful.

Resolve this by only warning if the builtin macro name is the name of
a macro defined by the language. This is done in a way that removes
some of the existing checks, as those were made redundant by
restricting the warning in this way.

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

This revision implements the Fortran intrinsic procedures COMPILER_VERSION and COMPILER_OPTIONS from the iso_fortran_env module.
To be able to set the COMPILER_OPTIONS string according to the original compiler driver invocation, a string is passed to the frontend driver using the environment variable FLANG_COMPILER_OPTIONS_STRING, for lack of a better mechanism.

Fixes #59233

Reviewed By: awarzynski

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

Starting with the SDKs provided with Xcode 14.3, this library no longer
exists. Before this change this results in an opaque linker error in the
case that your deployment target is low enough that this library is
added. This produces a more useful error message in that case.

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

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

Restructures the combined index based promotion and internalization
decision code so that it is a bit easier to follow. This is in
preparation for a bugfix to this code that will modify one part of the
logic.

Reviewed By: #libc, philnik

Spies: libcxx-commits

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

Reviewed By: ldionne, #libc

Spies: libcxx-commits, miyuki

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

The SCCPSolver is using a structure (AnalysisResultsForFn) where it keeps
pointers to various analyses needed by the IPSCCP pass. These analyses are
requested all at the same time, which can become problematic in some cases.
For example one could be retrieved via getCachedAnalysis() prior to the
actual execution of the analysis. In more detail:

The IPSCCP pass uses a DomTreeUpdater to preserve the PostDominatorTree
in case the PostDominatorTreeAnalysis had run before IPSCCP. Starting with
commit 1b123204 the IPSCCP pass may use BlockFrequencyAnalysis for
some functions in the module. As a result, the PostDominatorTreeAnalysis
may not run until the BlockFrequencyAnalysis has run, since the latter
analysis depends on the former. Currently, we setup the DomTreeUpdater
using getCachedAnalysis to retrieve a PostDominatorTree. This happens
before BlockFrequencyAnalysis has run, therefore the cached analysis can
become invalid by the time we use it.

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

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

This new channel data type was added in OpenCL C 3.0.

This replaces some uses of internal libc++ macros with the equivalent
macro from "test_macros.h".

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

This removes the need for contributors to do some manual steps
when adding a new public header.

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

If the step is not loop-invariant, we cannot create a modified AddRec,
as the start needs to be loop-invariant. Mark those cases as
CannotAnalyze and bail out, to fix a crash.

[NFC][TargetTransformInfo] Make getInliningThreholdMultiplier and getInlinerVectorBonusPercent const

Reviewed By: jlebar

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

The existing BOLT install targets are broken on Windows becase they
don't properly handle the output extension. We cannot use the existing
LLVM macros since those make assumptions that don't hold for BOLT. This
change instead implements custom macros following the approach used by
Clang and LLD.

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

Serves the dual purpose of avoiding an extra InstCombine iteration
for the DL-aware folding and removing one icmp constexpr use.

[z/OS] Disable pr59765-modules-global-ctor-dtor.cppm

Reviewed By: SeanP

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

Disable conversion of funnel shifts (fshl/fshr) into rotates
unless one of the operands is known to be a constant value.

Reviewed By: nikic

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

This reverts commit 559d47a1.

Caused failure on sanitizer-aarch64-linux-bootstrap-ubsan:

    clang++: /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Transforms/Utils/SCCPSolver.cpp:442: llvm::ValueLatticeElement &llvm::SCCPInstVisitor::getValueState(llvm::Value *): Assertion `!V->getType()->isStructTy() && "Should use getStructValueState"' failed.

Explicitly remove the old add instruction, so we don't need a
separate InstCombine iteration to DCE it.

FoldSetCC() returns UNDEF in a number of cases. However, the SetCC
result must follow BooleanContents. Unless the type is a
pre-legalization i1 or we have UndefinedBooleanContents, the use of
UNDEF will not uphold the requirement that the top bits are either
zero or match the low bit. In such cases, return zero instead.

Fixes https://github.com/llvm/llvm-project/issues/63055.

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