If `__builtin_frame_address` or `__builtin_return_address` is invoked with
non-zero argument, show an error message instead of a crash.

Reference: https://reviews.llvm.org/rG83b88441ad951fe99c30402930ef3cd661f2fd2b

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

'J' is defined in GCC [1] but not documented [2] while Linux [3] has
already used it in LoongArch port.

[1]: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/loongarch/constraints.md#L61
[2]: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html
[3]: https://github.com/torvalds/linux/blob/master/arch/loongarch/include/asm/cmpxchg.h#L19

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

A statement function in Fortran may be called, but it may not be the target
of a procedure pointer or passed as an actual argument.

This commit adds support for 32 bit absolute and pc relative relocations in
ELF/i386 objects, along with simple regression tests.

Reviewed By: sgraenitz, lhames

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

Some of the circumstances that require that a procedure have an
explicit interface at a point of call due to a characteristic of
a dummy argument apply to dummy procedures, too.

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

for (I = Start; I < End; I += 1) always terminates so mark
{scf|affine}.for as RecursivelySpeculatable when step is known to be
1.

Reviewed By: chelini

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

This is a vestige of the original MachO-specific edge set and was never used
as a generic aarch64 edge kind.

Disable the test that corresponds to a semantic check that was
disabled to work around an MSVC build problem.

A Fortran program may not specify a particular attribute multiple
times for the same entity in a scope.

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

Currently, InstCombine can elide a memcpy from a constant to a local alloca if
that alloca is passed as a nocapture parameter to a *function* that's readnone
or readonly, but it can't forward the memcpy if the *argument* is marked
readonly nocapture, even though readonly guarantees that the callee won't
mutate the pointee through that pointer. This patch adds support for detecting
and handling such situations, which arise relatively frequently in Rust, a
frontend that liberally emits readonly.

A more general version of this optimization would use alias analysis to check
the call's ModRef info for the pointee, but I was concerned about blowing up
compile time, so for now I'm just checking for one of readnone on the function,
readonly on the function, or readonly on the parameter.

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

As mentioned in https://discourse.llvm.org/t/rfc-extend-ranges-infrastructure-to-better-match-c-20/65377

Lambda objects are not copy assignable, and therefore neither are
iterator types which hold a lambda.  STL code require iterators be
copy assignable.  Users may not use mapped_iterator with a std::deque
for example: https://godbolt.org/z/4Px7odEEd

This blog post [1] explains the problem and solution.  We define a
wrapper class to store callable objects with two specialization.

1. Specialization for non-function types
    - Use a std::optional as storage for non-function callable.
    - Define operator=() implementation(s) which use
      std::optional::emplace() instead of the assignment operator.
2. Specialization for function types
    - Store as a pointer (even if template argument is a function reference).
    - Default construct pointer to nullptr.

This Callable wrapper class is now default constructible (with invalid
state) and copy/move assignable.

With these new properties available on the callable object,
mapped_iterator can define a default constructor as well.

[1] https://www.fluentcpp.com/2019/04/16/an-alternative-design-to-iterators-and-ranges-using-stdoptional/

Reviewed By: kazu

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

When a dummy argument is a procedure pointer without INTENT(IN),
any actual argument must also be a procedure pointer, whether the
dummy procedure pointer's interface is explicit or not.

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

Also invalidate block and loop dispositions during non-trivial
unswitching.

Fixes #58564.

We implemented 19.3.4p1 literally in name resolution:

  A component name has the scope of its derived-type definition. Outside the type definition,
  it may also appear within a designator of a component of a structure of that type or as a
  component keyword in a structure constructor for that type.

and within the derived-type definition would resolve the "bare"
names of components in specification inquiries and other contexts to
those components, not to any symbols in the enclosing scopes.

It turns out that most Fortran compilers resolve only "bare" names thus
when they are type parameters, and the names of data and procedure components
do not shadow exterior symbols.  Adjust name resolution to follow that
precedent rather than what seems to be clear language in the standard.

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

Make a requested change to the wording of a fatal I/O error
message.

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

This was previously attempted in 2016 by colinl's D18770, but LLD tests
were missed, which caused the change to be reverted.

Setting --print-imm-hex by default brings llvm-objdump's behavior closer
in line with objdump, and it makes it easier to read addresses and
alignment from the disassembly. It may make non-address immediates
harder to interpret, but it still seems the better default, barring more
context-sensitive base selection logic.

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

This prepares for an upcoming change to make --print-imm-hex the default
behavior of llvm-objdump. A few newly-added tests were missed the first
time around.

See D136972 for details.

This patch fixes:

  lld/MachO/SyntheticSections.cpp: In member function ‘virtual void
  lld::macho::ChainedFixupsSection::writeTo(uint8_t*) const’:

Previous attempt to work around a bogus error from MSVC 14 on
code from a recent patch failed, so add an #ifdef and disable
the feature for MSVC builds to get the build bot back up.

This patch fixes:

  lld/MachO/OutputSegment.cpp:50:43: warning: enumerated and
  non-enumerated type in conditional expression [-Wextra]

This reverts commit 95eaefd0.

I accidentally committed a patch to add a redundant typename.

The current test in printf-5.c appears to try to emit a volatile memcpy for the
format string, but it doesn't because the volatile qualifier is implicitly
casted away. Using a string literal instead preserves the volatile qualifier.

This is a follow-up to D137031 and is a prerequisite for D136822, which elides
memcpys in more instances and would otherwise break this test.

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

This patch fixes:

  llvm/lib/Target/AMDGPU/SIInstrInfo.cpp:7383: warning: enumerated
  mismatch in conditional expression:
  ‘llvm::AMDGPU::UfmtGFX11::UnifiedFormat’ vs
  ‘llvm::AMDGPU::UfmtGFX10::UnifiedFormat’

This patch fixes:

  llvm/lib/Target/Mips/MipsInstrInfo.cpp:71:52: warning: enumerated
  and non-enumerated type in conditional expression [-Wextra]

Recode a recent patch in an attempt to dodge a nonsensical error
from MSVC 14.

This patch fixes:

  llvm/lib/Target/Hexagon/HexagonVectorCombine.cpp:1554:6: warning:
  ‘llvm::Value*
  {anonymous}::HexagonVectorCombine::simplify(llvm::Value*) const’
  defined but not used [-Wunused-function]

This patch fixes:

  llvm/utils/unittest/googletest/include/gtest/gtest.h:1526:11: error:
  comparison of integers of different signs: 'const unsigned long' and
  'const int' [-Werror,-Wsign-compare]

[Re-submit after earlier revert due to a test failure. Commit dce78646
("clang-tblgen build: avoid duplicate inclusion of libLLVMSupport")
is believe to address the root cause of the test failure.]

Follow the pattern used in MLIR for the cl::opt instances.

v2:
- make DebugCounter::isCountingEnabled public so that the
  DebugCounterOwner doesn't have to be a nested class. This simplifies
  later changes

v3:
- remove the indirection via DebugCounterOwner::instance()

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

This patch fixes:

  flang/lib/Evaluate/fold-integer.cpp:613:25: error: lambda capture
  'name' is not used [-Werror,-Wunused-lambda-capture]

MSVC emits a warning on some recently patched code; fix it.

Pointer64Anon was lifted out of the MachO backend and into aarch64.h when that
header was created, but Pointer64Anon is really a MachO-specific "normalized"
relocation value, rather than a generic Edge::Kind. Any uses can be safely
replaced with Pointer64.

(Side note: the role of MachOPointer64Anon is to aid MachO relocation parsing:
For MachOPointer64, the target symbol is specified by the r_symbolnum field in
the relocation. For MachOPointer64Anon the address of the anonymous target is
read from the fixup location.)

The common language extension that allows arbitary expressions
to be used as components in a complex constructor (x,y) -- not both
constant, since that would make it a complex literal constant --
still have to be scalar; it's not an elemental operation like the
CMPLX() intrinsic function is.

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

When the compile-time result value of a reference to an integer-valued intrinsic
function COUNT, ICHAR, IACHAR, INDEX, SCAN, or VERIFY cannot be represented in
the selected result kind, emit a warning.

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

These are the same asserts we have in other query routines; cover this interface too.

These overrides should now match the default WriteShuffle schedules

This also fixes a typo where we were missing load latencies for the memory folded variants

We have similar code to translate a demanded elements mask for a shuffle's operands in multiple places - this patch adds a helper function to VectorUtils and updates a number of locations to use it directly.

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

Enforce remaining semantic restrictions on the arguments to MOVE_ALLOC,
namely that the first two arguments must be allocatable (!) and that
if the source is polymorphic, so must the destination be.

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