When the final phase is linking, Clang currently places `.dwo` files in the
current directory (like the `-c` behavior for multiple inputs).
Strangely, -fdebug-compilation-dir=/-ffile-compilation-dir= is considered, which
is untested.

GCC has a more useful behavior that derives auxiliary filenames from the final
output (-o).
```
gcc -c -g -gsplit-dwarf d/a.c d/b.c      # a.dwo b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c -o e/x  # e/x-a.dwo e/x-b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c         # a-a.dwo a-b.dwo
```

Port a useful subset of GCC behaviors that are easy to describe to Clang.

* Add a driver and cc1 option -dumpdir
* When the final phase is link, add a default -dumpdir if not specified by the user
* Forward -dumpdir to -cc1 command lines
* tools::SplitDebugName prefers -dumpdir when constructing the .dwo filename

GCC provides -dumpbase. If we use just one of -dumpdir and -dumpbase,
-dumpbase isn't very useful as it appends a dash.

```
gcc -g -gsplit-dwarf -dumpdir e d/a.c   # ea.dwo
gcc -g -gsplit-dwarf -dumpdir e/ d/a.c  # e/a.dwo
gcc -g -gsplit-dwarf -dumpbase e d/a.c  # e-a.dwo
gcc -g -gsplit-dwarf -dumpbase e/ d/a.c # e/-a.dwo
```

If we specify both `-dumpdir` and `-dumpbase`, we can avoid the influence of the
source filename when there is one input file.
```
gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c        # f/x.dwo
gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c d/b.c  # f/x-a.dwo f/x-b.dwo
```

Given the above examples, I think -dumpbase is not useful.

GCC -save-temps has interesting interaction with -dumpdir as -save-temps
generated files are considered auxiliary files like .dwo files.

For Clang, with this patch, -save-temps and -dumpdir are orthogonal, which is
easier to explain.

```
gcc -g -gsplit-dwarf d/a.c -o e/x -dumpdir f/ -save-temps=obj # e/a.{i,s,o,dwo}
gcc -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # f/a.{i,s,o,dwo}

clang -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # e/a.{i,s,o} f/a.dwo
```

Reviewed By: dblaikie

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

Add missing test coverage for D150029.

Put an intentional "trailing" space back in
FormatTestComments.SplitCommentIntroducers. It was removed in
a4c87f8c by mistake.

Reviewed By: MaskRay, dmgreen

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

The lowerbound was not correctly normalized to 0 when the bound
are generated for an array without subscripts.

```
integer :: a(11:20)
!$acc enter data create(a)
```

Reviewed By: razvanlupusoru

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

IRMutation::mutateModule() currently requires the bitcode size of the module.
To compute the bitcode size, one way is to write the module to a buffer using
BitcodeWriter and calculating the buffer size. This would be fine for a single
mutation, but infeasible for repeated mutations due to the large overhead. It
turns out that the only IR strategy weight calculation method that depends on
the current module size is InstDeleterStrategy, which deletes instructions more
frequently as the module size approaches a given max size. However, there is no
real need for the size to be in bytes of bitcode, so we can use a different
metric. One alternative is to let the size be the number of objects in the
Module, including instructions, basic blocks, globals, and aliases. Although
getting the number of instructions is still O(n), it should have significantly
less overhead than BitcodeWriter. This suggestion would cause a change to the
IRMutator API, since IRMutator::mutateModule() c...

The LEB128 type defined by the DWARF standard is explicitly a variable-length
encoding of an integer. LLDB had defined `uleb128` and `sleb128` types
to be 32-bit  but in many places in both LLVM and LLDB we treat the maximum
width of LEB128 types to be 64, so let's remove these types and be
consistent.

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

The implied-do index value has 'index' type, and it has to be
converted to the original ac-do-variable's data type.

Reviewed By: jeanPerier

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

Since the new data operand operations have been added in D148389 and
adopted on acc.data in D149673, the old clause operands are no longer
needed.

The LegalizeDataOpForLLVMTranslation will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.

processOperands will also receive some updates once all the operands
will be coming from an acc data operand operation.

Reviewed By: razvanlupusoru

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

This addresses the ARM issue found by:
https://lab.llvm.org/buildbot/#/builders/109/builds/63726

(This test wouldn't run for me locally, hence missing it in the last fix.)

It seems we were testing the behavior of the debug messages!

Avoid inferring new submodules for headers in ASTWriter's collection of
affecting modulemap files, since we don't want to pick up dependencies
that didn't actually exist during parsing.

rdar://109112624

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

This reverts commit 626aa851.

While investigating a bug in Clang, I noticed that -Wframe-larger-than
was emitting extra debug information along with the diagnostic. It
turns out that 2e1e2f52 fixed an issue
with the diagnostic, but accidentally left in some debug code that was
exposed in all builds.

So now we no longer emit things like:
8/4294967304 (0.00%) spills, 4294967296/4294967304 (100.00%) variables
along with the diagnostic

This addresses the issues found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/34937

The lowerbound was not correctly normalized to 0 when the bound
are generated for an array without subscripts.

```
integer :: a(11:20)
!$acc enter data create(a)
```

Reviewed By: razvanlupusoru

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

KCFI machine function passes transform indirect calls with a
cfi-type attribute into architecture-specific type checks bundled
together with the calls. Instead of having a separate pass for each
architecture, add a generic machine function pass for KCFI and
move the architecture-specific code that emits the actual check to
TargetLowering. This avoids unnecessary duplication and makes it
easier to add KCFI support to other architectures.

Reviewed By: nickdesaulniers

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

Spotted this one while working on new DWARF Rewriter. We were using wrong check
in assertion.

Reviewed By: Amir

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

Since the new data operand operations have been added in D148389 and
adopted on acc.exit_data in D149601, the old clause operands are no longer
needed.

The LegalizeDataOpForLLVMTranslation will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.

processOperands will also receive some updates once all the operands
will be coming from an acc data operand operation.

Reviewed By: jeanPerier

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

This diff switches the approach to comparison of constraint expressions
to the new one based on template args substitution.
It continues the effort to fix our handling of out-of-line definitions
of constrained templates.
This is a recommit of 3a540229.

Differential revision: https://reviews.llvm.org/D146178

Do not link asan_rtl_x86_64.S for non x86_64 platforms.

Prior to this CL asan_rtl_x86_64.S would be always be linked when
building compiler-rt for non x86_64 platforms, this normally isn't an
issue since at that link time is an empty file anyway.

When attempting to link a Aarch64 program with branch protection enabled
with the address sanitizer.

E.g.
```
clang --target=aarch64 \
      -fsanitize=address \
      -mbranch-protection=standard \
      -Wl,-z,force-bti
      -o test \
      test.cc
```

Results in the linking error from the sections generated from the empty
asan_rtl_x86_64.S owed to missing a .note.gnu.property

Also see [[ https://bugs.chromium.org/p/chromium/issues/detail?id=1427165 | https://bugs.chromium.org/p/chromium/issues/detail?id=1427165 ]]

Reviewed By: vitalybuka

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

In order to use the -stop-before/after infrastructure. Also remove the
creator function for M68kConvertMOVToMOVMPass, which has never been
created.

NFC.

* As no format string is involved, avoid unecessary call into `Printf`
* Eliminate creation of a `std::string` to print a `StringRef`

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

Revert "[AggressiveInstCombine] folding load for constant global patterened arrays and structs by GEP-indices Differential Revision: https://reviews.llvm.org/D146622 Fixes https://github.com/llvm/llvm-project/issues/61615"

This reverts commit 0574a4be. It causes a compiler crash due to a div by zero.

Instead of using SmallVectors of SmallVectors, use a plain array.

Reviewed By: c-rhodes

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

Self clause is the same same as the host clause. Lower it
in a simmilar way.

Reviewed By: razvanlupusoru

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

Previously, if a class with a defined public virtual destructor is
declared before including <initializer_list> and initializer_list is
provided via a Clang module, then overload resolution would fail for
std::initializer_list. This is because when Clang sees the virtual
destructor, Clang creates an implicit NamespaceDecl for std to
implicitly declare a std::bad_alloc. That NamespaceDecl is not added to
the translation unit's lookup table, so when the module containing
std::initializer_list is imported later, that module's std NamespaceDecl
can't find the previous std NamespaceDecl during redeclaration lookup,
causing overload resolution to fail.

To fix this, implicitly created std NamespaceDecls are now added to the
lookup map. At the same time, their IdentifierNamespace members are
cleared to prevent regular name lookups from finding it.

Fixes 60929

Reviewed By: ChuanqiXu, #clang-language-wg, inclyc

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

While we cannot handle `_Pragma` used inside macros, we can handle
this at the top level, and it some projects use the `_Pragma("once")`
spelling like that, which was causing spurious failures in the scanner.

Limitations
* Cannot handle #define ONCE _Pragma("once"), same issue as using
  @import in a macro -- ideally we should diagnose this in obvious cases
* Our LangOpts are currently fixed, so we are not handling u"" strings
  or R"()" strings that require C11/C++11.

rdar://108629982

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

We had some custom classes that were used as the predicate for
`std::find_if`. It would be a lot simpler if we used lambdas instead.

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

This patch fixes the printing of device information. Devices are initialized
before printing its information. Fixes #61392

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

Some time ago a patch was merged to disable all clang-tidy warnings
from system macros. This led to bugprone-assert-side-effect
silently no longer working, since the warnings came from a system
macro. The problem was not detected because the fake assert functions
were implemented in the same file as the test, instead of being a
system include like it's done in the real world.

Move the assert to a proper system header, and fix the code to
warn at the correct location.

This patch is breakdown from https://reviews.llvm.org/D147081
by PiotrZSL.

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

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

Currently blocks are always created with UnknownLoc's for their arguments. This
adds an `arg_locs` argument to all block creation APIs, which takes an optional
sequence of locations to use, one per block argument. If no locations are
supplied, the current Location context is used.

Reviewed By: ftynse

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

Follow up of https://reviews.llvm.org/D149979 for lowering.

In Fortran, it is possible to assign a pointer to another pointer
with an undefined association status.
When using the runtime do to none trivial pointer association, if the
descriptor are garbage, the runtime cannot safely detect that it has
a garbage descriptor, and it cannot safely know the descriptor size
leading to undefined behavior.
Another reason to initialize descriptor of pointers is to record any
non deferred length parameter value.
Hence, although this is not required by Fortran, f18 always initialize
pointers to NULL().
This was already done in lowering for whole pointer object, but not for
pointer components.

This patch uses the related semantics patch that updated
derivedTypeSpe::HasDefaultInitialization to ensure pointer components
of local and global object are always initialized.

It adds tests to ensure that allocation of such derived type uses the
runtime to ensure the storage is initialized, and that structure
constructors are setting the descriptor component to NULL() if no
initial target is given.

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

Since the new data operand operations have been added in D148389 and
adopted on acc.enter_data in D148721, the old clause operands are no longer
needed.

The LegalizeDataOpForLLVMTranslation will become obsolete when all
operations will be cleaned. For the time being only the appropriate
part are being removed.

processOperands will also receive some updates once all the operands
will be coming from an acc data operand operation.

Reviewed By: jeanPerier

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

The `if_present` clause is modeled as an attribute on the
acc.update operation. The lowering was not adding correctly the attribute
when the clause was present. This patch update the lowering to add
the attribute when needed.

Reviewed By: razvanlupusoru

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

https://reviews.llvm.org/D147773

Patch by Romaric Jodin <rjodin@google.com>

HIP may be installed into /usr or /usr/local on a variety of Linux
operating systems. It may become unwieldy to list them all.

Reviewed by: Siu Chi Chan, Yaxun Liu

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