VarTemplateSpecializationDecl does not store a template param list,
so the "template<>" needs to be stored in the ExtInfo.

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

The second argument to string::substr() is a count,
not an end position.

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

Close https://github.com/llvm/llvm-project/issues/61317

The root cause of the problem is that we profile TemplateName by the
non-canonical decls so that the compiler thought they are two different
types. But this is not true. We fixed the issue after we profile the
template name by using the same name.

The list of headers has also been updated. Some duplicated entrypoints
have been removed.

CodeGen used llvm.sext when converting fir.convert %0 : (i1) -> iXX
where iXX is any integer. This leads to wrong values when the initial
i1 is equal to 1.

Reviewed By: PeteSteinfeld

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

 * Add various options so that it uses the build lld and compiler-rt
 * Add instructions on how to use the newly built libc
 * Remove trailing comments in code-block for cut and pastability

Reviewed By: sivachandra

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

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

The macro llvmlibc_errno has also been removed. This change completes
the switch to using a hermetic errno for unit tests.

Fixes #61037

Reviewed By: lntue

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

Reviewed By: lntue

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

The small `Coverage` test was added because we added the space rule
about 2 at signs along with the rule about only 1 of it. We have not
fully covered covergroup yet.

Reviewed By: MyDeveloperDay, owenpan

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

Fix #61313

Reviewed By: lattner

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

Fixes #60684

Reviewed By: nemanjai

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

This reverts commit 97dcbea6.

Replace references to `enumerate` results with either const lvalue
rerences or structured bindings. I did not use structured bindings
everywhere as it wasn't clear to me it would improve readability.

This is in preparation to the switch to `zip` semantics which won't
support non-const lvalue reference to elements:
https://reviews.llvm.org/D144503.

Reviewed By: dblaikie

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

Some Fortran compilers allow kinds of LOGICAL other than C_BOOL
for the types of dummy arguments to interoperable (BIND(C))
procedures.  As any kind of LOGICAL can be converted to any
other without loss of information, this seems to be a useful
unambiguous extension that is attested in real codes; accept it
for scalars with a portability warning.

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

Previously we'd stash a null pointer in a sorted vector of CUs - the
next time around, we'd try to do a binary search in that vector (sorting
on a key inside the objects pointed to by the elements of the vector)
which would deref null if we'd stashed a null in there previously.

As a reasonable, but not ideal, workaround - don't stash any result in
the vector - this means every query will produce a new warning
(resulting in duplicate warnings) but better than a crash.

Stashing null in the list could be workable if we also stashed the
offset in a pair - but then all the clients would need to be fixed up
(maybe using a filtering iterator) which seems like overkill for this
uncommon error case.

The -Wunsafe-buffer-usage analysis outputs diagnostics in the order of
pointer values to associated `VarDecl`s. This creates non-determinism
in the order of diagnostics in output since the order cannot be
guaranteed in pointer values. However, our fix-it tests were written
under the assumption that diagnostics are output in source location
order.  This results in non-deterministic failures in our tests.  This
patch fixes the problem by keeping analysis results sorted by source
locations.

Reviewed by: jkorous, NoQ

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

MIPS Linux support was removed in ce03a862

Ensure metadata for declarations copied during materialization
is properly mapped if declarations do not become definitions.

Reviewed By: tejohnson

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

To be consistent with Triple.h, we update references to the
optional fourth triple field from ABI to env or enviornment

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

Extract the code the driver uses to expand response files and reuse it
in the dependency scanner.

rdar://106155880

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

As noted by @luke (https://reviews.llvm.org/D145953#inline-1409312), we were accounting for the cost of vector element size using vlenb whereas the expression can be constant folded for fixed length vectors.

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

Adds a doxygen comment on decodeBBAddrMap specifying what it does as well
as some requirements that need to be met when calling it (especially
the condition of passing in a relocation section when the ELFFile is
relocatable).

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

The new API matches a case we also need in MSAN.  For the moment, I'm staging this as a local-to-ASAN commit, but I expect to move this to a shared location and reuse in the next day or two.

The test was relying on the json module getting imported transitively by
one of its imported modules. Make this less brittle by importing it
explicitly.

After this patch all arbitrary size integers (smaller than 64 bits) in
LLVM IR will be promoted to regular size type in SPIR-V (OpTypeInt
8/16/32/64).

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

Currently when using the LLVM tools (eg llvm-readobj, llvm-objdump) to
find information about basic block locations using the propeller tooling
in relocatable object files function addresses are not mapped properly
which causes problems. In llvm-readobj this means that incorrect
function names will be pulled. In llvm-objdum this means that most BBs
won't show up in the output if --symbolize-operands is used. This patch
changes the behavior of decodeBBAddrMap to trace through relocations
to get correct function addresses if it is going through a relocatable
object file. This fixes the behavior in both tools and also other
consumers of decodeBBAddrMap. Some helper functions have been added
in/refactoring done to aid in grabbing BB address map sections now that
in some cases both relocation and BB address map sections need to be
obtained at the same time.

Regression tests moved around/added.

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

Warnings due to changes in behavior of cmake 3.20 or above.  See
https://cmake.org/cmake/latest/policy/CMP0116.html

Reviewed By: sivachandra

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

This is part of prework for supporting scalable vector types.  This isn't NFC because it shifts the point of failure (i.e. which assert triggers first), but should be NFC for all non-scalable vector inputs.

GCC on AIX primarily uses the -maix32 and -maix64 to select the bitmode
to target. In order to be compatible with existing build configurations,
clang should accept these options as well. In this patch we implement
these options for AIX targets.

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

This is a prepass on generalizing for scalable vectors; I'm just picking off the easy bits.