Use auto pointer/reference to fix llvm-qualified-auto remarks.

While this is mostly NFC right now, because only ARM happens
to run this pass with DomTree available before it,
and required after it, more backends will be affected once
the SimplifyCFG's switch for domtree preservation is flipped,
and DwarfEHPrepare also preserves the domtree.

We already ask for it, so it might be good to ensure that it is
actually initialized before us. Doesn't seem to matter in practice though.

FreeBSD uses -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface to
poison uses of floating point in its standalone environment. It also
deprecates machine/limits.h in favour of sys/limits.h and does not even
provide the former on newer architectures.

This is a cleaner reimplementation of equivalent patches in FreeBSD's
vendored copy of compiler-rt.

Reviewed By: dim

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

Now the only ones we're still missing from P0879
are `sort` and `nth_element`.

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

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

https://reviews.llvm.org/rG5369517d20dd362a178a1b2d6c398d8898ee4620
bumped the version number in __config to 13000, causing a test failure
in libcxx/test/libcxx/libcpp_version.pass.cpp because now the two
don't match.

This is the only part of the post-release TODO in
libcxx/docs/Contributing.rst that wasn't done by that commit.

Restriction on clauses for the EXIT DATA directive were not fully correct.
This patch fixes the situation. The async, if and finalize clauses are allowed
only once.

Reviewed By: SouraVX

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

Restriction on clauses for the HOST_DATA directive were not fully correct.
This patch fixes the situation. The if and if_present clauses are allowed
only once.

Reviewed By: SouraVX

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

Reviewed By: pengfei

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

Clangd currently throws away any protocol messages whenever an optional
field has an unexpected type. This patch changes the behaviour to treat
`null` fields as missing.

This enables clangd to be more tolerant against small violations to the
LSP spec.

Fixes https://github.com/clangd/vscode-clangd/issues/134

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

The check-libomptarget fails when building with LLVM_ENABLE_PROJECTS. This is because test configuration misses the path to libomp.so and libLLVMSupport.so when time profiling is enabled (both libraries have the same path when building). This patch add the path to the configuration.

Reviewed By: vzakhari

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

Fix when time profiling is enabled.

Related to: D94855

Reviewed By: JonChesterfield

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

llvmArchToWindowsSDKArch() returns "" for non-intel non-arm archs.
We're checking for "/fake/lib/" which is followed by the result
of that function -- but if that returns an empty string, then that
trailing slash isn't there. As fix, just explicitly pass a triple
that's intel or arm (I randomly chose aarch64). Since the test runs
with -###, that arch doesn't have to be in LLVM_TARGETS_TO_BUILD.

/vctoolsdir and /winsdkdir take precedence over the INCLUDE env var,
so they should also take precedence over LIB. It's not quite as neat
since LIB is still read by the linker and the linker just prefers
the -libpath: paths the driver now passes, but as long as all libraries
are present at /vctoolsdir and /winsdkdir, there's no harm in the linker
also looking at LIB later.

This fixes cl-options.c after a5d85cbe on Windows when LIB is set.
Another way to fix the test would be to prefix the clang-cl
line with `env --unset=LIB`, but I think it's better to fix the
flag to work as expected instead of making the test work around
the surprising behavior that LIB being set causes clang-cl to
not pass -libpath: flags to the linker when /vctoolsdir and
/winsdkdir are used.

This patch moves parsing of header search options from `generateCC1Options` to separate `GenerateHeaderSearchArgs`.

The round-trip algorithm in D94472 requires this separation to be able to run parsing and generating **only** for the options that need to be tested via round-tripping.

This also moves the `GENERATE_OPTION_WITH_MARSHALLING` to the top of the file, because other kinds of options will be generated in separate functions that will be spread throughout `CompilerInvocation.cpp` to be close to their parsing counterparts.

Reviewed By: dexonsmith

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

This patch moves parsing of header search options from `parseSimpleArgs` back to `ParseHeaderSearchArgs` where they originally were.

The round-trip algorithm in D94472 requires this separation to be able to run parsing and generating **only** for the options that need to be tested via round-tripping.

Reviewed By: dexonsmith

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

Port some OpenMP-related language options to the marshalling system for automatic command line parsing and generation.

Reviewed By: dexonsmith

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

This pre-commits tests for D95468.

`emplace???` functions running concurrently can set the ready flag and then pending awaiter will never be executed

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

Identical to previous commits that just add a standard library template to the
supported template list and test it. Adding this rather obscure class to the
template list is mostly caused by the std::deque test unexpectedly referencing
this type when testing against newer libc++ versions on macOS.

Fixes TestQueueFromStdModule and TestQueueFromStdModule on macOS.
Fixes rdar://73213589

This is a fix for PR48790. Over in D70350, subprogram DIEs were permitted
to be shared between CUs. However, the creation of a subprogram DIE can be
triggered early, from other CUs. The subprogram definition is then created
in one CU, and when the function is actually emitted children are attached
to the subprogram that expect to be in another CU. This breaks internal CU
references in the children.

Fix this by redirecting the creation of subprogram DIEs in
getOrCreateContextDIE to the CU specified by it's DISubprogram definition.
This ensures that the subprogram DIE is always created in the correct CU.

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

Moved information detailing the implementation from UsersManual
into OpenCLSupport page as it is not relevant to the user's of
clang but primarily needed for the compiler developers.

Tags: #clang

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

Currently only used by MoveChecker but ideally all checkers
should have reusable categories.

These do for the Windows SDK path what D85998 did for
%VCToolsInstallDir% with /vctoolsdir: Offer a way to set them with an
explicit commandline switch.

With this (and /vctoolsdir), it's possible to compile and link
against hermetic vctools and winsdk directories with:

    out/gn/bin/clang-cl win.c -fuse-ld=lld \
        /vctoolsdir path/to/VC/Tools/MSVC/14.26.28801 \
        /winsdkdir path/to/win_sdk

compared to a long list of -imsvc and /link /libpath: flags.

While here:
- Change the case of the "Include" folder inside the windows sdk
  from "include" to "Include" to match on-disk case. Since the
  Windows file system is case-insensitive this isn't a behavior
  change, it's just a bit cleaner.
- Add libpath tests to the /vctoolsdir
- Add a FIXME about reading env vars for win sdk and ucrt sdk
  if these flags aren't present, to match the VCToolsInstallDir
  logic

We should also cache all these computed paths in the driver instead
of computing them every time they're queried, but that's for a future
patch.

It'd also be nice to invent a /winsysroot: flag that sets both
/vctoolsdir: and /winsdkdir: to some well-known subdirectory.
That's for a future patch as well.

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

In computeLoadConstantCompareExitLimit, the addrec used to compute the
exit count should be from the loop which the exiting block belongs to.

Reviewed by: mkazantsev

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

This change makes `DeclarationNameLoc` a proper class and refactors its
users to use getter methods instead of accessing the members directly.
The change also makes `DeclarationNameLoc` immutable (i.e., it cannot
be modified once constructed).

Reviewed By: aprantl

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

This moves SinkIntoLoop from MachineLICM to MachineSink. The motivation for
this work is that hoisting is a canonicalisation transformation, but we do not
really have a good story to sink instructions back if that is better, e.g. to
reduce live-ranges, register pressure and spilling. This has been discussed a
few times on the list, the latest thread is:

https://lists.llvm.org/pipermail/llvm-dev/2020-December/147184.html

There it was pointed out that we have the LoopSink IR pass, but that works on
IR, lacks register pressure informatiom, and is focused on profile guided
optimisations, and then we have MachineLICM and MachineSink that both perform
sinking. MachineLICM is more about hoisting and CSE'ing of hoisted
instructions. It also contained a very incomplete and disabled-by-default
SinkIntoLoop feature, which we now move to MachineSink.

Getting loop-sinking to do something useful is going to be at least a 3-step
approach:

1) This is just moving the code and is almost a NFC, but contains a bug fix.
This uses helper function `isLoopInvariant` that was factored out in D94082 and
added to MachineLoop.
2) A first functional change to make loop-sink a little bit less restrictive,
which it really is at the moment, is the change in D94308. This lets it do
more (alias) analysis using functions in MachineSink, making it a bit more
powerful. Nothing changes much: still off by default. But it shows that
MachineSink is a better home for this, and it starts using its functionality
like `hasStoreBetween`, and in the next step we can use `isProfitableToSinkTo`.
3) This is the going to be he interesting step: decision making when and how
many instructions to sink. This will be driven by the register pressure, and
deciding if reducing live-ranges and loop sinking will help in better
performance.
4) Once we are happy with 3), this should be enabled by default, that should be
the end goal of this exercise.

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

This adds sadd.sat, uadd.sat, ssub.sat and usub.sat costs for AArch64,
similar to how they were recently added for ARM.

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

This patch fixes some crashes coming from
`RISCVISelLowering::getSetCCResultType`, which would occasionally return
an EVT constructed from an invalid MVT, which has a null Type pointer.

The attached test shows this happening currently for some fixed-length
vectors, which hit this issue when the V extension was enabled, even
though they're not legal types under the V extension. The fix was also
pre-emptively extended to scalable vectors which can't be represented as
an MVT, even though a test case couldn't be found for them.

Reviewed By: craig.topper

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

Ensure diagnostics from the prescanner are reported when running `flang-new -fsyntax-only` (i.e. only syntax parsing).
This keeps the diagnostics output of flang-new consistent with `f18 -fparse-only` when running the syntax parsing action, ParseSyntaxOnlyAction.

Summary of changes:
- Modify ParseSyntaxOnlyAction::ExecuteAction to report diagnostics

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

... and similarly for some other cases. This is for consistency and to
make it easier to search for mentions of a particular architecture.

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

This adds some simple fp16 scalar_to_vector patterns, preventing a
selection failure if this came up.

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

This makes G_SADDE and G_SSUBE legal in preparation for further work
legalizing overflowing operations. It's fine that they don't have an
instruction selector implementation yet, because G_UADDE and G_USUBE are
already legal on AArch64 without an instruction selector implementation. This
completes the set of G_[SU]{ADD,SUB}[EO] operations on AArch64.

Reviewed By: paquette

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

The included test case triggered a sign assertion on the result in
`Success()`.  This was caused by the APSInt created for a bitcast
having its signedness bit inverted.  The second APSInt constructor
argument is `isUnsigned`, so invert the result of
`isSignedIntegerType`.

Relanding this patch after reverting.  The test case had to be updated
to be insensitive to 32/64-bit extractelement indices.

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

Without this, the array can end up being an empty array leading to
compiler failures.

Problem reported by Joseph Shen <joseph.smeng@gmail.com>.
The patch changes *(&<atomic-var>) to (&<atomic-var>)->load().

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