This prepare the code for rework to collect all nececcecary data before
symbolization. Symbolization as any untrivial computations may affect
hwasan metadata.

Added pass optimizes MLProgram global operations by reducing to only
the minimal load/store operations for global tensors. This avoids
unnecessary global operations throughout a program and potentially
improves operation gusion.

Reviewed By: jpienaar

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

If we have a gather load whose indices correspond to valid offsets for a
gather with element type twice that our source, we can reduce the number
of indices and perform the operation at the larger element type.

This is generally profitable since we half VL - and these operations are
linear in VL. This may require some additional VL/VTYPE toggles, but
this appears to be worthwhile on the whole.

I missed this before I committed.

Android triples include a version number, which makes direct triple
comparisons for per-target runtime directory searching not always work.
Instead, look for the triple with the highest compatible version number
and use that per-target runtime directory instead. This maintains the
existing fallback to a triple without any version number, but I'm hoping
we can remove that in the future. https://discourse.llvm.org/t/62717
discusses this further.

The one remaining triple mismatch after this is that Android armv7
triples usually have an environment of `androideabi`, which Clang
normalizes to `android`. If you use the `androideabi` triple when
building the runtimes with a per-target runtimes dir, the directory will
get created with `androideabi` in its name, but Clang's triple search
uses the normalized triple and will look for an `android` directory
instead. https://reviews.llvm.org/D140925 will fix that by normalizing
triples when creating the per-target runtimes directories as well.

Reviewed By: phosek, pirama

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

LDR_PXI is a load instruction, so it should be in isLoadFromStackSlot.

[WPD][LLD] Add option to validate RTTI is enabled on all native types and prevent devirtualization on types with native RTTI

Discussion about this approach: https://discourse.llvm.org/t/rfc-safer-whole-program-class-hierarchy-analysis/65144/18

When enabling WPD in an environment where native binaries are present, types we want to optimize can be derived from inside these native files and devirtualizing them can lead to correctness issues. RTTI can be used as a way to determine all such types in native files and exclude them from WPD providing a safe checked way to enable WPD.

The approach is:
1. In the linker, identify if RTTI is available for all native types. If not, under `--lto-validate-all-vtables-have-type-infos` `--lto-whole-program-visibility` is automatically disabled. This is done by examining all .symtab symbols in object files and .dynsym symbols in DSOs for vtable (_ZTV) and typeinfo (_ZTI) symbols and ensuring there's always a match for every vtable symbol.
2. During thinlink, if `--lto-validate-all-vtables-have-type-infos` is set and RTTI is available for all native types, identify all typename (_ZTS) symbols via their corresponding typeinfo (_ZTI) symbols that are used natively or outside of our summary and exclude them from WPD.

Testing:
ninja check-all
large Meta service that uses boost, glog and libstdc++.so runs successfully with WPD via --lto-whole-program-visibility. Previously, native types in boost caused incorrect devirtualization that led to crashes.

Reviewed By: MaskRay, tejohnson

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

To fix issue: https://github.com/llvm/llvm-project/issues/66664

`CXXCtorInitializer` may not refer to a FieldDecl because it might also
denote another constructor call.

Fixes #66324

In 014c41d6 I tried to fix these tests,
but it seems that I needed to change TEST for TEST_F to make that work.
It's a pain that these failures don't repro on any of my machines, but I
verified thta the initialization code for the tests is invoked.

This warning needs to be disabled. The format string is deliberately too
large.

This reverts commit 4898c335.

Lots of buildbots are failing, probably because lots of targets not supporting
large _BitInt types.

This test was broken by 710276a2 because
DumpDataExtractor now accesses the Target properties, which someone ends
up relying on the file system.

This is an instance of this error https://lab.llvm.org/buildbot/#/builders/96/builds/45607/steps/6/logs/stdio

I cannot reproduce this locally, but it seems that the error happens
because we are not initializing the FileSystem and the Host as part of
the test setup.

We have been getting errors from emscripten users where including the
name of the symbol that triggered the inclusion would be useful in the
diagnosis. e.g:
https://github.com/emscripten-core/emscripten/issues/20275

This config is not actually used anywhere and it is not used on Android.
Since it does not test anything not tested elsewhere, remove it.

Remove the size class data associated with this config too.

Add first VPlan-based recipe simplification to fold (MUL A, 1) -> A.
Among other things, this enables additional simplifications after
applying versioned strides, as follow up to D147783.

Reviewed By: Ayal

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

evalIntegralCast was using makeIntVal, and when _BitInt() types were
introduced this exposed a crash in evalIntegralCast as a result.

Improve evalIntegralCast to use makeIntVal more efficiently to avoid the
crash exposed by use of _BitInt.

This was caught with our internal randomized testing.

<src-root>/llvm/include/llvm/ADT/APInt.h:1510:
  int64_t llvm::APInt::getSExtValue() const: Assertion
  `getSignificantBits() <= 64 && "Too many bits for int64_t"' failed.a

...
 #9 <address> llvm::APInt::getSExtValue() const
  <src-root>/llvm/include/llvm/ADT/APInt.h:1510:5
  llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>,
  clang::ento::SVal, clang::QualType, clang::QualType)
  <src-root>/clang/lib/StaticAnalyzer/Core/SValBuilder.cpp:607:24
clang::Expr const*, clang::ento::ExplodedNode*,
clang::ento::ExplodedNodeSet&)
  <src-root>/clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp:413:61
...

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

 Reviewed By: donat.nagy

This should be repaired.  Fixes build bots quickly.

Introduced:
https://reviews.llvm.org/D146169

Given the transition into using opaque pointers we no longer need to
add casts to handle "mismatched pointer types" as all pointers types
involved now are the same.

Given that transition to opaque pointers a call to CreatePointerCast
in processMemSetMemCpyDependence was found redundant. It would cast
from "ptr" to "ptr" (both associated with the same address space).

Given the transition to opaque pointers we no longer need to emit
some pointer casts. Int8PtrTy was set up to be a ptr in same address
space a OrigDest, making the first CreatePointerCast dead. And then
NewDestGEP will end up having the same type as OrigDest, making the
second CreatePointerCast dead.

The CFI_CDESC_T(rank) macro defined for C (not C++) in
ISO_Fortran_binding.h incorporates a cdesc_t structure as a member,
which works for data layout but doesn't allow for direct access to its
members. (The C++ definition can use inheritance.)

Restructure the definitions in that header file so that
CFI_CDESC_T(rank) for C defines a struct with the expected members.

This change corrects some cases where the source location for an
instantiated specialization of a function template or a member function
of a class template was assigned the location of a non-defining
declaration rather than the location of the definition the
specialization was instantiated from.

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

Reviewed By: cor3ntin

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

When a DATA statement object is not valid, there's a number of possible
reasons. Emit an error message for the most egregious violation, so that
an unlucky user doesn't fix something easy (due to a less-severe error
message masking one that is worse) and then run into something that
might be more serious.

Broken debug information can give empty names for an inlined frame, e.g,
```

0x1d605c68: ryKeyINS7_17SmartCounterTypesEEESt10shared_ptrINS7_15AsyncCacheValueIS9_EEESaIhESt6atomicEEE9fetch_subElSt12memory_order at   Filename: edata.h
  Function start filename: edata.h
  Function start line: 266
  Function start address: 0x1d605c68
  Line: 267
  Column: 0
 (inlined by)  at   Filename: edata.h
  Function start filename: edata.h
  Function start line: 274
  Function start address: 0x1d605c68
  Line: 275
  Column: 0
 (inlined by) _EEEmmEv at   Filename: arena.c
  Function start filename: arena.c
  Function start line: 1303
  Line: 1308
  Column: 0
```

This patch avoids creating a sample context with an empty function name
by stopping tracking at that frame. This prevents a hash failure that
leads to an ICE, where empty context serves at an empty key for the
underlying MapVector
https://github.com/llvm/llvm-project/blob/7624de5beae2f142abfdb3e32a63c263a586d768/llvm/lib/ProfileData/SampleProfWriter.cpp#L261

…mmy argument

Several compilers accept a null pointer (with or without a MOLD=) as an
actual argument for association with an INTENT(IN) allocatable dummy
argument. At runtime, the allocatable dummy argument appears to be in
the unallocated state. This seems useful, unambiguous, unlikely to
invalidate conforming code, and works with Intel, NAG, & XLF, so it
should be supported with an optional portability warning in this
compiler as well.

7d81813d says that this was used because functions missing certain
attributes (e.g. fast math) would inherit behavior from previous
functions with those attributes. However, later c378e52c explicitly set
those attributes if they were missing and removed the use of
DefaultOptions.

Semantic checking of COMMON blocks and EQUIVALENCE sets has an
assumption that the base storage sequence object of each COMMON block
object will also be in that COMMON block's list of objects, and emits an
error message when this is not the case. This assumption is faulty; it
is possible for a base object to have its COMMON block set during offset
assignment.

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

Searching for target-specific standard library header and library paths
should perform fallback searches for targets, the same way searching for
the runtime libraries does. It's important for the header and library
searches to be consistent, otherwise we could end up using mismatched
headers and libraries. (See also https://reviews.llvm.org/D146664.)

Reviewed By: phosek

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

https://reviews.llvm.org/D71154 prevented Clang from search for libc++
headers installed alongside the driver when targeting Android. The
motivation was the NDK's use of a different libc++ inline namespace
(`__ndk1` instead of the standard `__1`), which made regular libc++
headers incompatible with the NDK's libc++ library.

Since then, libc++ has gained the ability to install its `__config_site`
header (which controls the inline namespace, among other things) to a
per-target include directory, which enables per-target customizations.
If this directory is present, the user has expressly built libc++ for
Android, and we should use those headers.

The motivation is that, with the current setup, if a user builds their
own libc++ for Android, they'll use the library they built themselves
but the NDK's headers instead of their own, which is surprising at best
and can cause all sorts of problems (e.g. if you built your own libc++
with a different ABI configuration). It's important to match the headers
and libraries in that scenario, and checking for an Android per-target
include directory lets us do so without regressing the original scenario
which https://reviews.llvm.org/D71154 was addressing.

While I'm here, switch to using sys::path::append instead of slashes
directly, to get system path separators on Windows, which is consistent
with how library paths are constructed (and that consistency will be
important in a follow-up, where we use a common search function for the
include and library path construction).

(As an aside, one of the motivations for https://reviews.llvm.org/D71154
was to support targeting both Android and Apple platforms, which
expected libc++ headers to be provided by the toolcain at the time.
Apple has since switched to including libc++ headers in the platform SDK
instead of in the toolchain, so that specific motivation no longer
applies either.)

Reviewed By: phosek

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

Projects like libc++ include their own cache files, and it's convenient
to just be able to reuse those cache files as part of a runtimes build
instead of having to duplicate the settings inside a special runtimes
cache file (which will inevitably get out of sync).

I'm not completely happy about overloading the existing argument passing
behavior based on the argument name, but I also couldn't think of a good
alternative. Suggestions are welcome.

Reviewed By: phosek

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

The Fortran standards require (F'2023 C745) that a derived type with the
SEQUENCE attribute have at least one component. No Fortran compiler
actually enforces this constraint. Accept this usage with a warning.

Reviewed By: #libc, var-const

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

A NULL() pointer is an acceptable actual argument for association with
an (absent) optional allocatable dummy argument. Semantics was
unconditionally emitting an error that the actual argument is not
allocatable.