Inline assembly is scary but we need to support it for the OpenMP GPU
device runtime. The new assumption expresses the fact that it may not
have call semantics, that is, it will not call another function but
simply perform an operation or side-effect. This is important for
reachability in the presence of inline assembly.

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

Before we gave up if a call through bitcast had parameter attributes.
Interestingly, we allowed attributes for the return value already. We
now handle both the same way, namely, we drop the ones that are
incompatible with the new type and keep the rest. This cannot cause
"more UB" than initially present.

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

Reviewed By: arsenm

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

glibc sysdeps/aarch64/tst-vpcs-mod.S has something like:
```
.variant_pcs    vpcs_call
.global vpcs_call
```

This is supported by GNU as but leads to an error in MC. Use getOrCreateSymbol
to support a not-yet-registered symbol: call `registerSymbol` to ensure the
symbol exists even if there is no binding directive/label, to match GNU as.

While here, improve tests to check (1) a local symbol can get
STO_AARCH64_VARIANT_PCS (2) undefined .variant_pcs (3) an alias does not
inherit STO_AARCH64_VARIANT_PCS.

Reviewed By: efriedma

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

Reviewed By: abrachet

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

Reviewed By: luismarques

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

This makes Fuchsia consistent with Linux on AArch64.

Reviewed By: abrachet

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

The clang driver to picks up compiler runtime files using full paths.
Without this, at least for aarch64, the driver tries to pick up the
compiler runtime files from the working directory.

Reviewed By: michaelrj

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

Platforms may define uintptr_t differently, so perform an explicit cast

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

Use a separate templated QuarantineBlocks class to avoid a zero-length array

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

Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks rely on 2 invariants:

1) For frontend instrumentation, MD_prof branch_weights will always be
   populated before llvm.expect intrinsics are lowered.

2) for IR and sample profiling, llvm.expect intrinsics will always be
   lowered before branch_weights are populated from the IR profiles.

These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.

Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.

Reviewed By: tejohnson

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

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:472:16: warning: enumeration value 'HLSL' not handled in switch [-Wswitch]
    switch (IK.getLanguage()) {
               ^

.eh_frame pieces may be dropped due to GC/ICF. When --emit-relocs adds
relocations against .eh_frame, the offsets need to be adjusted. Use the same
way as MergeInputSection with a special case handling outSecOff==-1 for an
invalid piece (see eh-frame-marker.s).

This exposes an issue in mips64-eh-abs-reloc.s that we don't reliably
handle anyway. Just add --no-check-dynamic-relocations to paper over it.

Original patch by Ayrton Muñoz

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

Seeing a test failure with asan in Halide generated code, reverting
while I investigate.

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

* Improve eh-frame-merge.s
* Delete invalid .eh_frame+5 test in ehframe-relocation.s

Been >2 weeks since flipped to Both, following update procedure and
flipping to prefixed.

This builtin returns the address of a global instance of the
`std::source_location::__impl` type, which must be defined (with an
appropriate shape) before calling the builtin.

It will be used to implement std::source_location in libc++ in a
future change. The builtin is compatible with GCC's implementation,
and libstdc++'s usage. An intentional divergence is that GCC declares
the builtin's return type to be `const void*` (for
ease-of-implementation reasons), while Clang uses the actual type,
`const std::source_location::__impl*`.

In order to support this new functionality, I've also added a new
'UnnamedGlobalConstantDecl'. This artificial Decl is modeled after
MSGuidDecl, and is used to represent a generic concept of an lvalue
constant with global scope, deduplicated by its value. It's possible
that MSGuidDecl itself, or some of the other similar sorts of things
in Clang might be able to be refactored onto this more-generic
concept, but there's enough special-case weirdness in MSGuidDecl that
I gave up attempting to share code there, at least for now.

Finally, for compatibility with libstdc++'s <source_location> header,
I've added a second exception to the "cannot cast from void* to T* in
constant evaluation" rule. This seems a bit distasteful, but feels
like the best available option.

Reviewers: aaron.ballman, erichkeane

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

Been >2 weeks since flipped to Both, following update procedure and
flipping to prefixed.

There's a vulnerability in 1.2.11:
https://twitter.com/taviso/status/1508438583484452866

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

Calling an ObjC method from a C function marked with the 'enforce_tcb'
attribute did not produce a warning. Now it does, and on top of that
Objective-C methods can participate in TCBs themselves.

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

First of all, this is the convention: all other tools have their
dependencies private. While it does not have an effect on linking
(there is no linking against executables), it does have an effect
on exporting: having the targets private allows installing the tools
without the libraries in a statically linked build, or a build against
libclang-cpp.so.

Reviewed By: v.g.vassilev

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

Not sure if this could use more testing, but hopefully this is adequate.

This is a fix for #53963.

Reviewed By: aaron.ballman

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

Fixes #54513

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

Bringing in HLSL as a language as well as language options for each of
the HLSL language standards.

While the HLSL language is unimplemented, this patch adds the
HLSL-specific preprocessor defines which enables testing of the command
line options through the driver.

Reviewed By: pete, rnk

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

This patch makes -version valid, and --version invalid, for
flang-new -fc1. The invocation
  flang-new --version
remains valid. This behaviour is consistent with clang
(and with clang -cc1 and clang -cc1as).

Previously, flang-new -fc1 accepted --version (as per Options.td), but
the frontend driver acutally checks for -version. As a result,
  flang-new -fc1 --version
triggered no action, emitted no message, and stalled waiting for
standard input.

Fixes #51438

Reviewed By: PeteSteinfeld, awarzynski

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

STB_GNU_UNIQUE should be treated in a way similar to STB_GLOBAL.
This fixes an "Invalid Binding" failure in an LLVM_ENABLE_ASSERTIONS=on build
for source files like glibc elf/tst-unique1mod1.c .

This bug has been benign so far because (a) Clang does not produce
%gnu_unique_object by itself (b) a non-assertion build likely picks the
STB_GLOBAL code path anyway.

select (~a | c), a, b -> and a, (or c, b) https://alive2.llvm.org/ce/z/bnDobs
select (~c & b), a, b -> and b, (or a, c) https://alive2.llvm.org/ce/z/k2jJHJ

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

In a recent run, temp files got created in /tmp/lit-tmp-2wcrtcx1/foo-xxx.o.
Since the tmp path contained "crt", this made a few tests fail:
http://45.33.8.238/linux/72221/step_7.txt

Not allowing '/' as path of the file name prevents this.

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

The change of https://reviews.llvm.org/D121513#3411651
has caused a build error when building with clang:

/mnt/vss/_work/1/llvm-project/mlir/lib/Dialect/Tosa/IR/TosaOps.cpp:599:26: error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
ReduceFolder(ReduceAllOp);

Reviewed By: hpmorgan, Mogball

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

This change adds a stub DirectX target for clang to enable targeting
dxil targets.

Reviewed By: pete

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

Modified DAGCombiner to pass the shift the bittest input and the shift amount
to hasBitTest. This matches the other call to hasBitTest in TargetLowering.h

This is an alternative to D122454.

Reviewed By: luismarques

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

Issue #54554

Adds another pointer to the union in RegionRange to allow RegionRange to work on ArrayRef<Region *> (i.e. vectors of Region *).

Reviewed By: rriddle

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

(This was a TODO from the initial patch).

The control-flow sink utility accepts a callback that is used to sink an operation into a region.
The `moveIntoRegion` is called on the same operation and region that return true for `shouldMoveIntoRegion`.
The callback must preserve the dominance of the operation within the region. In the default control-flow
sink implementation, this is moving the operation to the start of the entry block.

Reviewed By: mehdi_amini

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

Summary:
  hasHostcallPtr() and hasHeapPtr() are only used in metadata emit.
However, we can use the corresponding function attributes directly
instead introducing the functions.

Reviewers: arsenm

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

Summary:
Address post-commit review comments in the https://reviews.llvm.org/D82549, including

changed file name from llvm/test/tools/llvm-readobj/XCOFF/xcoff-auxiliary-header.test --> llvm/test/tools/llvm-readobj/XCOFF/auxiliary-header.test
replaced macro define by using lambda function.
added a helper function to reduce the duplicated check and print error code.

Reviewer : James Henderson
Differential Revision: https://reviews.llvm.org/D116220