Example: https://lab.llvm.org/buildbot/#/builders/239/builds/4709

This simply puts the profiling logic into the `Profiler` class and
allows non-RAII profiling via `beginSection` and `endSection`.

This patch expose the type and attribute names in C++ as methods in the
`AbstractType` and `AbstractAttribute` classes, and keep a map of names
to `AbstractType` and `AbstractAttribute` in the `MLIRContext`. Type and
attribute names should be unique.

It adds support in ODS to generate the `getName` methods in
`AbstractType` and `AbstractAttribute`, through the use of two new
variables, `typeName` and `attrName`. It also adds names to C++-defined
type and attributes.

This reverts commit 52b4b357.

This commit was causing build failures on bots without libpfm installed
as the CHECK requires were not set correctly. The test added should only
run on machines with libpfm enabled due to the limitations currently
imposed by the subprocess execution mode.

So that when mixing small and large text, large text stays out of the
way of the rest of the binary.

This is useful for mixing precompiled small code model object files and
built-from-source large code model binaries so that the the text
sections don't get merged.

The reland fixes an issue where a function in the large code model would reference small data without GOTOFF.

The DWARF proposal that the DW_LNCT_LLVM_source extension is based on
(https://dwarfstd.org/issues/180201.1.html) allows to mix source and
non-source files in the same CU by storing an empty string as a
sentinel value.

This patch implements this feature.

Review in https://github.com/llvm/llvm-project/pull/73877

This reverts commit 4ed51957.

My #73541 added lines to
`llvm/utils/lit/tests/Inputs/testrunner-custom-parsers/test.txt` so what
was previously on line 7 is now on line 12.

Before:

https://github.com/llvm/llvm-project/blob/28412d1800e391c5ba8e7607bb15c74b106d581b/llvm/utils/lit/tests/Inputs/testrunner-custom-parsers/test.txt#L7-L8

After:

https://github.com/llvm/llvm-project/blob/6fb7c2d713587a061cd281eda917746750559380/llvm/utils/lit/tests/Inputs/testrunner-custom-parsers/test.txt#L12-L13

This didn't show up in the PR checks, but caused a buildbot failure
after merging, https://lab.llvm.org/buildbot/#/builders/139/builds/54597
:

```
# | ======================================================================
# | FAIL: test_commands (__main__.TestIntegratedTestKeywordParser)
# | ----------------------------------------------------------------------
# | Traceback (most recent call last):
# |   File "/home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/utils/lit/tests/unit/TestRunner.py", line 135, in test_commands
# |     self.assertEqual(value[1].command.strip(), "%dbg(MY_RUN: at line 7)  foo  bar")
# | AssertionError: '%dbg(MY_RUN: at line 12)  foo  bar' != '%dbg(MY_RUN: at line 7)  foo  bar'
# | - %dbg(MY_RUN: at line 12)  foo  bar
# | ?                      ^^
# | + %dbg(MY_RUN: at line 7)  foo  bar
# | ?                      ^
```

Apologies for the build break 🙀

Fix a failure on Linux system where follow-fork-mode
exists, which caused the large watchpoint NFC patch
to be reverted earlier this week.

Tries to fix:

    ../../lldb/source/Breakpoint/WatchpointResource.cpp:59:12:
    error: no member named 'find' in namespace 'std'; did you mean 'fill'?
          std::find(m_constituents.begin(), m_constituents.end(), wp_sp);
          ~~~~~^~~~
               fill

(cherry picked from commit a6c62bf1)

On macOS <vector> was already included via another
header file, but this failed on the CI bots.  I'd
tested on linux earlier in this patch's life when
the headers were differently arranged.

(cherry picked from commit a0a1ff3a)

This patch is rearranging code a bit to add WatchpointResources to
Process. A WatchpointResource is meant to represent a hardware
watchpoint register in the inferior process. It has an address, a size,
a type, and a list of Watchpoints that are using this
WatchpointResource.

This current patch doesn't add any of the features of
WatchpointResources that make them interesting -- a user asking to watch
a 24 byte object could watch this with three 8 byte WatchpointResources.
Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at
0x1003, these must both be served by a single WatchpointResource on that
doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint
registers were used to track these separately, one of them may not be
hit. Or if you have one Watchpoint on a variable with a condition set,
and another Watchpoint on that same variable with a command defined or
different condition, or ignorecount, both of those Watchpoints need to
evaluate their criteria/commands when their WatchpointResource has been
hit.

There's a bit of code movement to rearrange things in the direction I'll
need for implementing this feature, so I want to start with reviewing &
landing this mostly NFC patch and we can focus on the algorithmic
choices about how WatchpointResources are shared and handled as they're
triggeed, separately.

This patch also stops printing "Watchpoint <n> hit: old value: <x>, new
vlaue: <y>" for Read watchpoints. I could make an argument for print
"Watchpoint <n> hit: current value <x>" but the current output doesn't
make any sense, and the user can print the value if they are
particularly interested. Read watchpoints are used primarily to
understand what code is reading a variable.

This patch adds more fallbacks for how to print the objects being
watched if we have types, instead of assuming they are all integral
values, so a struct will print its elements. As large watchpoints are
added, we'll be doing a lot more of those.

To track the WatchpointSP in the WatchpointResources, I changed the
internal API which took a WatchpointSP and devolved it to a Watchpoint*,
which meant touching several different Process files. I removed the
watchpoint code in ProcessKDP which only reported that watchpoints
aren't supported, the base class does that already.

I haven't yet changed how we receive a watchpoint to identify the
WatchpointResource responsible for the trigger, and identify all
Watchpoints that are using this Resource to evaluate their conditions
etc. This is the same work that a BreakpointSite needs to do when it has
been tiggered, where multiple Breakpoints may be at the same address.

There is not yet any printing of the Resources that a Watchpoint is
implemented in terms of ("watchpoint list", or
SBWatchpoint::GetDescription).

"watchpoint set var" and "watchpoint set expression" take a size
argument which was previously 1, 2, 4, or 8 (an enum). I've changed this
to an unsigned int. Most hardware implementations can only watch 1, 2,
4, 8 byte ranges, but with Resources we'll allow a user to ask for
different sized watchpoints and set them in hardware-expressble terms
soon.

I've annotated areas where I know there is work still needed with
LWP_TODO that I'll be working on once this is landed.

I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS.

https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
(cherry picked from commit fc6b7252)

Now that FreeBSD 14.0 has been released make the 12.x branch the oldest
supported releases. -fuse-init-array defaults to on. DWARF 4 is now the
default.

In AIX, the following testcase fails in attempt to delete the current
directory, exiting current directory before removing

---------

Co-authored-by: Mark Danial <mmark.danial@ibm.com>

Fix off-by-one error in comment.

Early return is accepted in OpenACC loop not directly nested in a
compute construct. Since acc.loop operation has a region, the
`func.return` operation cannot be directly used inside the region.
An early return is materialized by an `acc.yield` operation returning a
`true` value. The standard end of the `acc.loop` region yield a `false`
value in this case.
A conditional branch operation on the `acc.loop` result will branch to
the `finalBlock` or just to the continue block whether an early exit was
produce in the acc.loop.

Fixes a bug that appended values after insertion completed. Also slight
optimization by avoiding all-Dense computation for every lexInsert call

Found while running libc++'s test suite with MSVC's STL.

`ADDITIONAL_COMPILE_FLAGS` is a `ParserKind.LIST`:

https://github.com/llvm/llvm-project/blob/3c23ed156f0151923b168bdff0c34ec73fb37f38/libcxx/utils/libcxx/test/format.py#L104-L108

With a comma-separated example:

https://github.com/llvm/llvm-project/blob/3c23ed156f0151923b168bdff0c34ec73fb37f38/libcxx/utils/libcxx/test/format.py#L223-L228

And comma-separated test coverage:

https://github.com/llvm/llvm-project/blob/dd3184c30ff531b8aecea280e65233337dd02815/libcxx/test/libcxx/selftest/additional_compile_flags/substitutes-in-run.sh.cpp#L12-L15

Because the machinery splits on commas:

https://github.com/llvm/llvm-project/blob/dd09221a29506031415cad8a1308998358633d48/llvm/utils/lit/lit/TestRunner.py#L1882-L1883

https://github.com/llvm/llvm-project/blob/dd09221a29506031415cad8a1308998358633d48/llvm/utils/lit/lit/TestRunner.py#L1951-L1956

However, most (although not all) usage of `ADDITIONAL_COMPILE_FLAGS` is
treating it as space-separated. That apparently works in the normal
Clang environment, but in my exotic configuration it causes `"-DMEOW
-DWOOF"` to be passed as a single argument to MSVC, which then emits
"warning C5102: ignoring invalid command-line macro definition
`'_LIBCPP_DISABLE_DEPRECATION_WARNINGS
-D_LIBCPP_ENABLE_CXX26_REMOVED_CODECVT'`", causing test failures due to
warnings-as-errors.

This PR changes `ADDITIONAL_COMPILE_FLAGS` to actually be parsed as a
space-separated list, and changes the few uses/examples that had commas.

Summary:
Currently, the `libomp.so` and `libomptarget.so` are emitted in the
`./lib` build directory generally. This logic is internal to the
`add_llvm_library` function we use to build `libomptarget`. The
DeviceRTl static library however is in the middle of the OpenMP runtime
build, which can vary depending on if this is a runtimes or projects
build. This patch changes this to install the DeviceRTL static library
alongside the other OpenMP libraries so they are easier to find.

Using the known/unknown value of the sign bit, reason about the signedness version of the dot4 instruction.

Removes some unnecessary testing of dump and dot file formats, to
simplify updates to this test.

Summary:
Previously, we determined that coarse grained memory cannot be used in
the general case. That removed the buffer used to transfer the memory,
however we still had this lookup. Though we do not access the symbol
directly, it still conflicts with the agents apparently. Pin this as
well.

This resolves the problems @lntue was having with the `libc` GPU build.

…ion result)

A function can't return a statement function, so an apparent attempt to
define a statement function with the same name as the function's result
must be a misparsed assignment statement.

When a reference to a function-like macro begins during the rescanning
of the expansion of another macro but is not completed by the end of
that expansion, it is necessary to abort that rescanning of that
expansion and try again when more tokens can be acquired. (See the new
unclosed-FLM.F90 test case.) All other Fortran preprocessors to which I
have access can handle this situation.

Some clauses can be repeated on the compute construct when they are
placed after `device_type`. The semantic check was reporting an error
for these cases. This patch fixes this.

This reverts commit 97e16da4 because it
causes build error on i386 system.

…n actual argument is contiguous

When an element of a contiguous pointer array or assumed-shape array is
associated as an actual argument with an assumed-size dummy array, don't
flag the usage as an error.

Array element references are frequently parsed as function references
due to the ambiguous syntax of Fortran, and the parse tree is repaired
by semantics once the relevant symbol table entries are in hand. This
patch fixes a case in which the correction takes a path that leaves the
type of a symbol undetermined, leading to later spurious errors in
expression analysis.

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

…ortran_binding.h

... and into the ISO_Fortran_binding_wrapper.h header, through which the
compiler and runtime access its contents. This change ensures that user
code that #includes ISO_Fortran_binding.h within 'extern "C" {' doesn't
encounter mysterious namespace errors.

As already documented in flang/docs/Extensions.md and implemented in the
compilation-time format validator, we want to support at execution time
the Intel (and presumably also Fujitsu) extension of allowing a missing
width on an edit descriptor in a formatted I/O statement.

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

The working directory is included in the PCM, but is not currently part
of the context hash. This causes problems because different builds of a
PCM with exactly the same command line can end up with different binary
content for a PCM. If a build system tracks tasks by both working
directory and command line, it may build a given PCM multiple times,
causing a "module file out of date" error when loading the PCM due to
different sizes.

A typo was leading to getc_unlocked.cpp.o being included into libc.a
twice.

I only noticed because I was trying to convert libc.a to a shared object
via

$ ld.lld -o libc.so --whole-archive libc.a

which errored since getc_unlocked was being defined twice.

A subtle bug in buffer management is being caused by a WRITE on an
unformatted file with variable-length records after one or more
BACKSPACEs and some READs. An attempt at a minor optimization in
BACKSPACE kept the footer of the previous record in the unit's buffer,
in case more BACKSPACEs were to follow. If a later WRITE takes place
instead, the buffer's frame would still cover that footer, but its
content would be lost when the buffer became dirty on its first
modification, and the footer in the file would be overwritten with stale
buffer contents. As WriteFrame() implies the intent to define all the
bytes in the identified range, the trick being used in BACKSPACE with
its adjustment to frameOffsetInFile_ breaks any later WRITE... and so we
just can't do it.

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

This reverts commit cb13e928.
Buildbot reports MSAN failures in tests added in this commit:
https://lab.llvm.org/buildbot/#/builders/5/builds/38806

Failing tests:
  LLVM :: CodeGen/BPF/preserve-static-offset/load-arr-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/load-ptr-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/load-struct-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/load-union-pai.ll
  LLVM :: CodeGen/BPF/preserve-static-offset/store-pai.ll

…arrays

When comparing dummy array extents, cope with references to symbols
better (including references to other dummy arguments), and emit
warnings in dubious cases that are not equivalent but not provably
incompatible.