I broke the build, and now I'm fixing it.

The various preloaded registers (workitem IDs, workgroup IDs, and
various implicit pointers) always have a finite, invariant, well-defined
value throughout a well-defined program.

In cases where the compiler infers or the user declares that some
implicit input will not be used (ex. via amdgcn-no-workitem-id-y), the
behavior of the entire program is undefined, since that misdeclaration
can cause arbitrary other preloaded-register intrinsics to access the
wrong register. This case is not expected to arise in practice, but
could occur when the no implicit argument attributes were not cleared
correctly in the presence of external functions, indrect calls, or other
means of executing un-analyzable code. Failure to detect that case would
be a bug in the attributor.

This commit updates the documentation to reflect this long-standing
reality.

Then, on the basis that all implicit arguments are defined in all
correct programs, the intrinsics that return those values are
annototated with `noundef``. Some implicit pointer arguments gain a
`nonnull`, but the kernel argument segment pointer or implicit argument
pointers don't necessarily have this property.

This will prevent spurious calls to `freeze` in front-end optimizations
that destroy user-provided ranges on built-in IDs.

(While I'm here, this commit adds a test for `noundef` on kernel
arguments which is currently unimplemented)

Ensure that a branch cannot be made into a case of a SELECT TYPE or
SELECT RANK construct.

When an I/O statement references a unit number that has not been
explicitly opened or predefined, the I/O runtime support library opens a
local "fort.N" file. If this fails, the program crashes, even when the
I/O statement has IOSTAT= or IOMSG= or ERR= control list items. Connect
the dots to enable resilience in these cases.

Some intrinsics (extends_type_of, same_type_as) can accept a NULL actual
argument so long as it has a MOLD=. Some intrinsics that are marked in
the intrinsics table as accepting a NULL actual argument already should
only do so if it has a MOLD=. Distinguish table entries that accept a
NULL() only with a MOLD= from the few others that allow a bare NULL()
and update tests.

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

…ILE dummies

There's language in the standard (F'2023 15.5.2.5 p21) disallowing an
actual argument with a vector subscript from associating with a dummy
argument with either the ASYNCHRONOUS or VOLATILE attributes. This is a
bug in the standard, as (1) these attributes are actually relevant only
over the scope of the called procedure, (2) they can be applied in
nested scopes (internal subprograms and BLOCK) within the called
procedure, and (3) can be implicit within the called procedure and its
nested scopes in the case of ASYNCHRONOUS as a side effect of using a
dummy argument in an asynchronous data transfer statement. So issue a
warning. This new warning about undefinable actual arguments being
associated with ASYNCHRONOUS and VOLATILE dummy arguments subsumes an
existing warning about passing a constant actual to a VOLATILE dummy.

Resolves https://github.com/llvm/llvm-project/issues/93600.

Problematic PR: https://github.com/llvm/llvm-project/pull/92843
Reverted by: https://github.com/llvm/llvm-project/pull/94088



The first PR added a test which fails in Linux builds (see the last few
comments there).
This PR contains all the changes in the first PR, plus the fix to the
said test.

---------

Co-authored-by: Roy Shi <royshi@meta.com>

The standard requires that dummy arguments to PURE functions be
INTENT(IN) or VALUE, but PURE subroutines are allowed to have modifiable
dummy arguments. This makes it impossible to declare atomic operations
as PURE functions, which consequently makes such atomic operations
ineligible for use in parallel constructs and DO CONCURRENT.

This patch downgrades this error to a warning by default, which can be
seen with -pedantic & al. and remain an error with -Werror.

Add option to generate additional debug info for expression dereferencing pointer to pointers.  (#94100)

This is another attempt to land #81545, which was reverted. 

Fixed test case by adding a target triple so that clang generates the same IR for all platforms

In accordance with other compilers, don't require that a %REF() actual
argument be a modifiable variable. And move the %REF/%VAL semantic
checks to Semantics/check-call.cpp, where one would expect to find them.

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

The code that used existing type declarations (if any) for the names
being used as dummy arguments in a statement function definition would
apply those types only if they came from EntityDetails symbols. This
broke a case in which the type was being inherited from a Cray pointee.

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

The return of malloc is implementation defined when the requested size
is 0. On platforms (such as AIX) that return a null pointer for 0 size,
operator new will throw a bad_alloc exception. operator new should
return a non null pointer for 0 size instead.

The intention is to check a section name different from
.gcc_except_table . Rather than using a linker script, use llvm-objcopy
--rename-section instead.

…lock specification expressions

A subroutine or function interface block is of course allowed to
USE-associate symbols into its scope and use them for specification
expressions. This usage works, but crashes the module file output
generator. Fix.

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

A DEFAULT_SYSROOT interfered with the test, apparently. See #94055.

We currently complain that the argument may not be a procedure, which is
confusing. Distinguish the NULL() case from other error cases (which are
indeed procedures). And clean up the utility predicates used for these
tests -- the current IsProcedure() is really just a test for a procedure
designator.

Fixes #94184.

Previously the `type_traits` target manually listed all of the type
traits files. This patch replaces that with a glob to make the build
simpler.

PR #92983 accidentally changed the buffer allocation in
`llvm::WriteBitcodeToFile` to be allocated on the stack, which is
problematic given it's a large-ish buffer (256K)

Summary:
These tools need to be built before we can do the library creation
stage. If they are generated in the same build then this is not
guaranteed so we should add explicit dependencies.

This patch introduces a new ExtractFromEnd VPInstruction opcode to
extract the value of a FOR for users outside the loop (i.e. in the
scalar loop's exits). This moves the first part of fixing first order
recurrences to VPlan, and removes some additional code to patch up
live-outs, which is now handled automatically.

The majority of test changes is due to changes in the order of which the
extracts are generated now. As we are now using VPTransformState to
generate the extracts, we may be able to re-use existing extracts in the
loop body in some cases. For scalable vectors, in some cases we now have
to compute the runtime VF twice, as each extract is now independent, but
those should be trivial to clean up for later passes (and in line with
other places in the code that also liberally re-compute runtime VFs).

PR: https://github.com/llvm/llvm-project/pull/93395

Some applications like to use a CPP-style #include directive to pull in
a common list of arguments, dummy arguments, or COMMON block variables
after a free-form & line continuation marker. This works naturally with
compilers that run an actual cpp pass over the input before doing
anything specific to Fortran, but it's a case that I missed with this
integrated preprocessor.

Most Fortran compilers accept "doubled operators" as a language
extension. This is the use of a unary '+' or '-' operator that is not
the first unparenthesized operator in an expression, as in 'x*-y'.

This compiler has implemented this extension, but in a way that's
different from other compilers' behavior. I interpreted the unary
'+'/'-' as a unary operator in the sense of C/C++, giving it a higher
priority than any binary (dyadic) operator.

All other compilers with this extension, however, give a unary '+'/'-' a
lower precedence than exponentiation ('**'), a binary operator that
C/C++ lacks. And this interpretation makes more sense for Fortran,
anyway, where the standard conforming '-x**y' must mean '-(x**y)'
already.

This patch makes 'x*-y**z' parse as 'x*-(y**z)', not 'x*(-y)**z)', and
adds a test to ensure that it does.

This is needed for the allocator implementation for malloc.

Summary:
You can build the GPU libc support in projects mode. There were some
issues with it not finding the correct binaries. This patch fixes that.

[clang][Sema] Don't issue -Wcast-function-type-mismatch for enums with a matching underlying type (#87793)

Enums are passed as their underlying integral type so they're ABI compatible if the size matches.
Useful with C APIs that pass user-controlled values to callbacks that can be made type safe by using enumerations (e.g. GStreamer).

Discovered internally in some code after 999d4f84.

Add patterns to label NVPTX backend related changes automatically.

Call InsertNewInstWith() instead of InsertNewInstBefore() when creating
"store to null" instruction

This means that CI won't have to hardcode these.

If a delete is pending on the file queried for status, a misleading
`permission_denied` error code will be returned (this is the correct
mapping of the error set by GetFileAttributesW). By querying the
underlying NTSTATUS code via ntdll's RtlGetLastNtStatus, this case can
be disambiguated. If this underlying error code indicates a pending
delete, fs::status will return a new `pending_delete` error code to be
handled by callers

Fixes #89137

Reverts llvm/llvm-project#94022

This is not actually valid bazel syntax. Buildbot failure: https://buildkite.com/llvm-project/upstream-bazel/builds/99430#018fdf11-6865-4d5d-be8e-7bfab59e3cd8

Summary:
The runtimes builds create separate projects. Normally these use
`LLVM_EANBLE_RUNTIMES`. However, we can also use `LLVM_RUNTIME_TARGETS`
and `RUNTIMES_<target>_LLVM_ENABLE_RUNTIMES` to enable them. Currently,
if `LLVM_RUNTIME_TARGETS` isn't specified this is completely ignored.
This patch fixes the behavior so we can only specify the cross-compiling
versions.

See #94000 for a report of a downstream failure, this fixes it.

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations

):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>

[cmake] Pass -resource-dir to external projects as CMAKE_<LANG>_FLAGS_INIT instead of as a force override (#87330)

It's useful to use toolchain files for configuring runtimes builds.
Setting `CMAKE_<LANG>_FLAGS` is however forceful and precludes initialization from the _INIT variant meant to be set by toolchains.
The toolchain file still needs to append instead of just setting and be idempotent (`include_guard()`), but this way at least a special toolchain to account for LLVM won't be required.

After #94055 this test failed on ARM/AArch64-hosted Windows, but it's
not clear why.

[lldb][test][NFC] TestBreakpointSetRestart.py: split up assertion to determine which check specifically fails in CI

This test consistently fails on the public macOS ASAN CI (and isn't
reproducible locally):
```
FAIL: test_breakpoint_set_restart_dwarf
(TestBreakpointSetRestart.BreakpointSetRestart)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1756, in test_method
    return attrvalue(self)
  File
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py",
line 150, in wrapper
    return func(*args, **kwargs)
  File
"/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/test/API/functionalities/breakpoint/breakpoint_set_restart/TestBreakpointSetRestart.py",
line 36, in test_breakpoint_set_restart
    self.assertTrue(bp.IsValid() and bp.GetNumLocations() == 1,
VALID_BREAKPOINT)
AssertionError: False is not true : Got a valid breakpoint
```

From this error we're not quite sure what about the breakpoint here is
the problem.

This patch splits up the assertion to narrow down the issue.

This argument allows to specify the path to make which is used by
LLDB API tests to compile test programs.
It might come in handy for setting up cross-platform remote runs of API tests on Windows host.

It can be used to override the make path of LLDB API tests using `LLDB_TEST_USER_ARGS` argument:
```
cmake ...
-DLLDB_TEST_USER_ARGS="...;--make;C:\\Path\\to\\make.exe;..."
...
```