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

Rename parameter in Sema::addInitCapture as proposed in review of Sema::addInitCapture. Sorry, that I have missed the comment there!

Reviewed By: ilya-biryukov

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

CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.

Reviewed By: kwk

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

Clang currently supports disabling color diagnostic output via
-fno-color-diagnostics. However, there is a somewhat long-standing push
to support use of an environment variable to override color output so
that users can set up their terminal such that most color output is
disabled (largely for accessibility reasons).

There are two competing de facto standards to accomplish this:
  NO_COLOR (https://no-color.org/) and
  CLICOLOR/CLICOLOR_FORCE (http://bixense.com/clicolors/).

This patch adds support for NO_COLOR as that appears to be the more
commonly supported feature, at least when comparing issues and pull
requests:
https://github.com/search?q=NO_COLOR&type=issues (2.2k issues, 35k pull requests)
https://github.com/search?q=CLICOLOR&type=issues (1k issues, 3k pull requests)

It's also the more straightforward and thoroughly-specified of the two
options. If NO_COLOR is present as an environment variable (regardless
of value), color output is suppressed unless the command line specifies
use of color output (command line takes precedence over the environment
variable).

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

Reviewed By: pcwang-thead

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

CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.

Reviewed By: mehdi_amini

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

CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.

Reviewed By: phosek

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

This reverts commit 6bcfab31.

Reverting because this breaks the build with MSVC

A function is already emitted in *GenInstrInfo.inc that takes Opcode
number and a set of supported Features and reports fatal error if some
of the required features are missing.

The information about features required by the particular opcode can be
reused by llvm-exegesis, so move its computation info a separate
computeRequiredFeatures() function. Then verifyInstructionPredicates()
can just compare the sets of available and required features computed by
the other functions.

This commit moves the definition of FeatureBitsets[] as well as CEFBS_*
enumerator values (that are indices into FeatureBitsets[] array) inside
the computeRequiredFeatures() function because these are implementation
details of that function. The inclusion of potentially huge
computeRequiredFeatures() function is now controlled by a dedicated
macro that is set for simplicity by TableGen-erated code itself if
`defined(ENABLE_INSTR_PREDICATE_VERIFIER) && !defined(NDEBUG)`.

~~

Huawei RRI, OS Lab

Reviewed By: courbet

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

Many command line option implementations, including getopt_long and our
Support/CommandLine.cpp, support `--` as an end-of-option indicator. All
the subsequent arguments are then treated as positional arguments.

D1387 added KIND_REMAINING_ARGS and 76ff1d91 dropped special handling of `--`.
Users need to add `def DASH_DASH : Option<["--"], "", KIND_REMAINING_ARGS>;` and
append `OPT_DASH_DASH` to the `OPT_INPUT` list., which is not ergonomic.

Restore this feature under an option and modify llvm-strings to utilize the
feature as an example. In the future, we probably should enable this feature by
default and exclude some tools that handle `DASH_DASH` differently (clang,
clang-scan-deps, etc. I suspect that many are workarounds for LLVMOption not
supporting `--` as a built-in feature).

Reviewed By: serge-sans-paille

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

LIBCXX_ENABLE_FILESYSTEM should represent whether the platform has
support for a filesystem, not just whether we support <filesystem>.
This patch slightly generalizes the setting to also encompass whether
we provide <fstream>, since that only makes sense when a filesystem is
supported.

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

Typically the size required to represent a dirent is stored in `d_reclen`. But
this not always the case for FreeBSD (for example, when walking a directory
over NFS).

This leads to ASAN false positives for `scandir` and similar functions. Because
ASAN uses `d_reclen` for the range to validate, it can overrun when `d_reclen` is
incorrect (too large).

This change adds `__sanitizer_dirsiz` which fixes the dirent size calculation
for FreeBSD. Other platforms continue to use `d_reclen`.

Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D151583

DeclPrinter::VisitCXXRecordDecl did not output qualifiers for records.
As result, the output of out-of-line record definitions was incorrect.

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

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

Currently, `retainedNodes` tracks function-local variables and labels.
To support function-local import, types and static variables (which are globals
in LLVM IR), subsequent patches use the same field. So this patch makes
preliminary refactoring of the code tracking local entities to apply future
functional changes lucidly and cleanly.

No functional changes intended.

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

We need to allow recursive application of intrinsic lowering patterns,
otherwise we cannot lower nested calls of the same intrinsic e.g.
matmul(matmul(a, b), c).

matmul(matmul(a, b), matmul(c, d)) requires hlfir.associate of hlfir
expr with more than one use (TODO).

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

The verifiers for hlfir.matmul and hlfir.transpose try to ensure that
the shape of the result value makes sense given the shapes of the input
argument(s).

It there are some cases in the gfortran tests where lowering knows a bit
more about shape information than (HL)FIR. I think the cases here will be
solved when hlfir.shape_meet is implemented.

But in the meantime, and to improve robustness, I've relaxed the
verifier to allow the return type to have more precise shape information
than can be deduced from the argument type(s).

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

For Neon, the default nonconst stride cost is conservative,
and it is a local variable, which is not convenience to
to tune the loop vectorize.
So I try to use a option, which is similar to SVEGatherOverhead brought in D115143.
Fix https://github.com/llvm/llvm-project/issues/63082.

Reviewed By: dmgreen, fhahn
Differential Revision: https://reviews.llvm.org/D152253

Reland "D144999 [MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs."

Reasons for rolling forward:
    - the crash reported from Chromium was fixed in D151824 (not related to this patch at all)
    - since D152824 was committed, it should now be safe to roll this forward.

New change:
    - add an additional _ in name check

This reverts commit 4980eead.

Device libs make use of patterns like this:
```
__attribute__((target("gfx11-insts")))
static unsigned do_intrin_stuff(void)
{
  return __builtin_amdgcn_s_sendmsg_rtnl(0x0);
}
```
For functions that are assumed to be eliminated if the currennt GPU target doesn't support them.
At O0 such functions aren't eliminated by common optimizations but often by AMDGPURemoveIncompatibleFunctions instead, which sees the "+gfx11-insts" attribute on, say, GFX9 and knows it's not valid, so it removes the function.

D142907 accidentally made it so such attributes were dropped during bitcode linking, making it impossible for RemoveIncompatibleFunctions to catch the functions and causing ISel to catch fire eventually.

This fixes the issue and adds a new test to ensure we don't accidentally fall into this trap again.

Fixes SWDEV-403642

Reviewed By: arsenm, yaxunl

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

- This patch proposes to add `!setdagarg` and `!setdagname` bang
  operators to produce a new DAG node after replacing the specified
  argument value/name from the given input DAG node. E.g.,
  `!setdagarg((foo 1, 2), 0, "x")` produces `(foo "x", 2)` and
  `!setdagname((foo 1:$a, 2:$b), 1, "c")` produces `(foo 1:$a, 2:$c)`.

Reviewed By: simon_tatham

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

We cannot lower VBROADCAST i16 under AVX1.

Fixes #63114

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

/data/llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:1621:3: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default]
  default:
  ^
/data/llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:1643:3: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default]
  default:
  ^
2 errors generated.

This adds a commutative version of VSelectPredOrPassthruPatFrags (renamed from
EitherVSelectOrPassthruPatFrags) that checks both variants for commutative
operations like min/max. I have not attempted to handle fp operation that
require fast-math flags.

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

[Clang][OpenMP][IRBuilder] Move registerTargetGlobalVariable & getAddrOfDeclareTargetVar into the OMPIRBuilder

This change tries to move registerTargetglobalVariable and
getAddrOfDeclareTargetVar out of Clang's CGOpenMPRuntime
and into the OMPIRBuilder for shared use with MLIR's OpenMPDialect
and Flang (or other languages that may want to utilise it).

This primarily does this by trying to hoist the Clang specific
types into arguments or callback functions in the form of
lambdas, replacing it with LLVM equivelants and
utilising shared OMPIRBuilder enumerators for
the clauses, rather than Clang's own variation.

Reviewers: jsjodin, jdoerfert

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

This fixes broken mingw builds since
0a71e25e. Clang-cl style builds
were broken similarly, but were fixed in
caa2c1ba, with the comment
"Do not redefine builtins on Windows", even if the fix only affected
Clang-cl style builds.

Adds a new HLFIR operation for the DOT_PRODUCT intrinsic according to
the design set out in flang/docs/HighLevel.md. This patch includes all
the necessary changes to create a new HLFIR operation and lower it into
the fir runtime call.

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

The `exit` entrypoint calls into `quick_exit` which is marked noreturn
in some cases. This will cause errors because we then have control flow
externally. This warning can be silenced by using a
`__builtin_unreachable` instruction accordingly.

Reviewed By: sivachandra, lntue

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

NFC.

This patch implemed the change proposed in [P2002R1] to 11.11.1 [class.compare.default] paragraph 1.

A defaulted compariosn operator function must be non-volatile and must either have no ref-qualifier or the ref-qualifier &.

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

Reviewed By: foad

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

Reviewed By: kadircet

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