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.

Doing so allows the use of smaller constants overall, and may allow (for some small vector constants) avoiding the constant pool entirely.  This can result in extra VTYPE toggles if we get unlucky.

This was reviewed under PR #66405.

The warning message about a derived type not having a FINAL subroutine
for a particular object's rank should not issue for an assumed-rank
dummy argument.

Minor refactoring to delete redundant code.

Reviewed By: jobnoorman

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

Memoize SymbolRef::getAddress() for sorting symbol table entries by
their address. Saves about 10 seconds of processing time on large
binaries with over 2 million symbols. NFCI.

Reviewed By: jobnoorman, Amir

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

…e pointer

The procedure characterization package correctly characterizes the
result of a reference to a function that returns a procedure pointer. In
the event of a result that is a pointer to a function that itself is a
procedure pointer, the code in pointer assignment semantics checking was
mistakenly using that result's procedure characteristics as the
characteristics of the original function reference. This is just wrong;
delete it.

This reverts commit efca035c.

Reverting due to windows build bot failure:
https://lab.llvm.org/buildbot/#/builders/13/builds/40242/steps/6/logs/stdio

The helper function `__pair_like_explicit_wknd` is only SFINAE-ed with
`tuple_size<remove_cvref_t<_PairLike>>::value == 2`, but its function
body assumes `std::get` being valid.

Fixes #65620

This test was reported as failing by https://lab.llvm.org/buildbot/#/builders/68/builds/60172. The fix is very simple. We need to invoke the correct setting.

This patch fixes a warning:

  flang/runtime/edit-input.cpp:27:20: error: unused function
  'IsListDirectedFieldComplete' [-Werror,-Wunused-function]

The method implementations remain in the .cpp file; explicit instantiations have been added for these two types. 
makeMatrix has been duplicated to makeIntMatrix and makeFracMatrix.