ClangAttrEmitter.cpp generates ParsedAttr derived classes with virtual overrides in them (which end up in AttrParsedAttrImpl.inc); this patch ensures these generated functions are marked override, and not (redundantly) virtual.

I hesitate to say NFC since this does of course affect the behavior of the generator code, but the generated code behaves the same as it did before, so it's NFC in that sense.

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

- Arguments of the first block of a region are considered region arguments.
- Add API on Region class to deal with these arguments directly instead of
  using the front() block.
- Changed several instances of existing code that can use this API
- Fixes https://bugs.llvm.org/show_bug.cgi?id=46535

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

Summary:
llvm-cov.test generates .gcov files and compared with target
sample files. Since the files do not contain any binary data
(files are plain ASCII texts), remove -a from diff. And this
fix will the error on AIX since the default diff tool on AIX
does not support -a option.

Reviewers: hubert.reinterpretcast, daltenty, stevewan

Subscribers: llvm-commits

Tags: #LLVM

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

- Avoid generating "assert(resultTypes.size() >= 0u)" which is always true

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

Loop metadata nodes do not adhere to the documented property:

(a) LoopIDs are not unique: Any pass that duplicates IR will do it
    including its metadata (e.g. LoopVersioning) such that multiple
    loops are linked with the same LoopID. There is even a test case
    (Transforms/LoopUnroll/unroll-pragmas-disabled.ll) for multiple
    loops with the same LoopID.

(b) LoopIDs are not persistent: Adding or removing an item from a LoopID
    can only be done by creating a new MDNode and assigning it to the
    loop's branch(es). Passes such as LoopUnroll (llvm.loop.unroll.disable)
    and LoopVectorize (llvm.loop.isvectorized) use this to mark loops to
    not be transformed multiple times or to avoid that a LoopVersioned
    original loop is transformed.

Update the documentation according to how llvm.loop is used in practice.

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

This patch adds override to several overriding virtual functions that were missing the keyword within the clang/ directory. These were found by the new -Wsuggest-override.

The libc++ headers were included twice, which broke the #include_next
logic.

Summary:
This patch extends the ModuleSpec class to include a
DataBufferSP which contains the module data. If this
data is provided, LLDB won't try to hit the filesystem
to create the Module, but use only the data stored in
the ModuleSpec.

Reviewers: labath, espindola

Subscribers: emaste, MaskRay, lldb-commits

Tags: #lldb

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

In synchronous mode, the process connect command and its aliases should
wait for the stop event before claiming the command is complete.
Currently, the stop event is always handled asynchronously by the
debugger.

The implementation takes the same approach as Process::ResumeSynchronous
which hijacks the event and handles it on the current thread. Similarly,
after this patch, the stop event is part of the command return object,
which is the property used by the test case.

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

Summary:
This is motivated by:
 - code completion: nice to do no i/o on the request path
 - background index: deciding whether to enqueue each file would stat the config
   file thousands of times in quick succession.

Currently it's applied uniformly to all requests though.

This gives up on performing stat() outside the lock, all this achieves is
letting multiple threads stat concurrently (and thus finish without contention
for nonexistent files).
The ability to finish without IO (just mutex lock + integer check) should
outweigh this, and is less sensitive to platform IO characteristics.

Reviewers: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

This is another problem raised in:
http://bugs.llvm.org/PR46627

Summary: While here, add documentation to CompileFlags and CompileFlags.Add.

Reviewers: hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Summary:
This can be run after a ninja-based build, and analyzes the ninja
build files and dependency database to spot any missing dependencies
in the build scripts.

I wrote it in the course of investigating D82659, and it seems likely
to be useful again.

Reviewers: thakis, chandlerc, theraven

Reviewed By: thakis

Subscribers: riccibruno, llvm-commits

Tags: #llvm

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

Instead of having complex logic around how to include the libc++ headers
and __config_site, handle that by defining cxx-headers as an INTERFACE
library and linking against it. After this patch, linking against cxx-headers
is sufficient to get the right __config_site include and include paths
for libc++.

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

Summary: Currently forward decls are included with all the op classes. But there are cases (say when splitting up headers) where one wants the forward decls but not all the classes. Add an option to enable this. This does not change any current behavior (some further refactoring is probably due here).

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

Summary:
Names of local variables have no linkage (see C++20 [basic.link] p8).

Names of variables in unnamed namespace have internal linkage (see C++20
[basic.link] p4).

Reviewers: aaron.ballman, rsmith, ymandel

Reviewed By: ymandel

Subscribers: cfe-commits

Tags: #clang

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

Summary:
This is designed for tweaking compile commands by specifying flags to add/remove
in a config file. Something like:
  CompileFlags: { Remove: -fcolor-diagnostics }

Having users tweak raw argv (e.g. with a regex) is going to end in tears: bugs
around clang-cl, xclang, aliases, joined-vs-separate args etc are inevitable.

This isn't in tooling because of the performance choices: build a big table
up-front to make subsequent actions fast. Maybe it should be though.

Reviewers: adamcz, hokein

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

The _ExtInt type allows custom width integers, but the atomic memory
access's operand must have a power-of-two size. _ExtInts with
non-power-of-two size should not be allowed for atomic intrinsic.

Before this change:

$ cat test.c

typedef unsigned _ExtInt(42) dtype;
void verify_binary_op_nand(dtype* pval1, dtype val2)
{    __sync_nand_and_fetch(pval1, val2); }

$ clang test.c

clang-11:
/home/ubuntu/llvm_workspace/llvm/clang/lib/CodeGen/CGBuiltin.cpp:117:
llvm::Value*
EmitToInt(clang::CodeGen::CodeGenFunction&, llvm::Value*,
clang::QualType, llvm::IntegerType*): Assertion `V->getType() ==
IntType' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace, preprocessed source, and associated run script.

After this change:

$ clang test.c

test.c:3:30: error: Atomic memory operand must have a power-of-two size
{    __sync_nand_and_fetch(pval1, val2); }
^

List of the atomic intrinsics that have this
problem:

__sync_fetch_and_add
__sync_fetch_and_sub
__sync_fetch_and_or
__sync_fetch_and_and
__sync_fetch_and_xor
__sync_fetch_and_nand
__sync_nand_and_fetch
__sync_and_and_fetch
__sync_add_and_fetch
__sync_sub_and_fetch
__sync_or_and_fetch
__sync_xor_and_fetch
__sync_fetch_and_min
__sync_fetch_and_max
__sync_fetch_and_umin
__sync_fetch_and_umax
__sync_val_compare_and_swap
__sync_bool_compare_and_swap

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

Because of the layout of stores (that don't have a destination operand)
this check is exactly the same as the one in
RISCVInstrInfo::isLoadFromStackSlot.

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

New test to show the changes after D81805 is committed.

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

Summary:
This patch implements lowering of OpenMP barrier construct from
pft to OpenMPDialect.

Patch is carved out of following merged PR's from fir-dev branch
of https://github.com/flang-compiler/f18-llvm-project/

PR's:
https://github.com/flang-compiler/f18-llvm-project/pull/248
https://github.com/flang-compiler/f18-llvm-project/pull/251

Unfortunately primary tool `bbc` for functional validation is not
yet upstreamed. So this patch includes a unittest for lowering
`!OMP barrier` construct.

Some part of the these PR's still remains downstream(functional test
and dialect registration to legalizer) for obvious reasons.
Will upstream them when the dependencies are upstreamed.

Reviewed By: schweitz, kiranchandramohan

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

This reverts commit f1efb8bb.

Reverted because it doesn't correctly update the pass return status, see

http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-debian/builds/9441/steps/test-check-all/logs/FAIL%3A%20LLVM%3A%3Awiden-i32-i8ptr.ll

Summary: Just unifying all that copy-pasted code.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

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

Imagine we have an YAML description for some object and we want to
produce 2 outputs: with and without the section header.
A natural way to do it would look like:

```
--- !ELF
FileHeader:
  Class:   ELFCLASS64
  Data:    ELFDATA2LSB
  Type:    ET_REL
  Machine: EM_X86_64
Sections:
...
SectionHeaderTable:
  NoHeaders: [[NOHEADERS]]

```
But currently, we do not distinguish between no `NoHeaders` key case
and `NoHeaders == false`. Because of this we can't simply specify
`NOHEADERS = false`, as tool starts to complain.

With this patch the behavior changed. When we have:

```
SectionHeaderTable:
  NoHeaders: false

```
it is the same as we have no `SectionHeaderTable` at all.
(`NoHeaders` key still can't be used with `Sections/Excluded` keys)

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

A miscompile with -0.0 is shown in:
http://bugs.llvm.org/PR46627

This is because maxnum(-0.0, +0.0) does not specify a fixed result:
http://llvm.org/docs/LangRef.html#llvm-maxnum-intrinsic

So we need to tighten the constraints for when it is ok to say the
result of maxnum is positive (including +0.0).

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

More coverage for D83601.

[test/Object][llvm-objdump] - llvm-objdump: don't abort() when the e_phoff field is invalid and refine testing.

llvm-objdump currently calls report_fatal_error() when the e_phoff field is invalid.

This is tested by elf-invalid-phdr.test which has the following issues:
1) It uses a precompiled object.
2) it could be a part of invalid.test.
3) It tests the Object lib, but we have no separate test for llvm-objdump.

This patch addresses issues mentioned.

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

program_headers() returns the list of program headers. This change allows
to continue attempt of dumping when something is wrong with program headers.

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

ComputeNumSignBits and computeKnownBits both trigger "Scalable flag
may be dropped" warnings when a fixed length vector is extracted
from a scalable vector.  This patch assumes nothing about the
demanded elements thus matching the behaviour when extracting a
scalable vector from a scalable vector.

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

The glob expression for a test called "test" could match a log file for
a the test "test_foo". Instead of globbing, maintain an explicit list of
log files relevant to the current test.

This patch adds support for emitting value forms of DW_FORM_strx,
DW_FORM_addrx, DW_FORM_loclistx and DW_FORM_rnglistx.

Reviewed By: jhenderson

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

A dozen 32-bit `AddressSanitizer` testcases FAIL on the latest beta of Solaris 11.4/x86, e.g.
`AddressSanitizer-i386-sunos :: TestCases/null_deref.cpp` produces

  AddressSanitizer:DEADLYSIGNAL
  =================================================================
  ==29274==ERROR: AddressSanitizer: stack-overflow on address 0x00000028 (pc 0x08135efd bp 0xfeffdfd8 sp 0x00000000 T0)
      #0 0x8135efd in NullDeref(int*) /vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10
      #1 0x8135ea6 in main /vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/null_deref.cpp:21:3
      #2 0x8084b85 in _start (null_deref.cpp.tmp+0x8084b85)

   SUMMARY: AddressSanitizer: stack-overflow /vol/llvm/src/llvm-project/dist/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10 in NullDeref(int*)
  ==29274==ABORTING

instead of the expected

  AddressSanitizer:DEADLYSIGNAL
  =================================================================
  ==29276==ERROR: AddressSanitizer: SEGV on unknown address 0x00000028 (pc 0x08135f1f bp 0xfeffdf48 sp 0xfeffdf40 T0)
  ==29276==The signal is caused by a WRITE memory access.
  ==29276==Hint: address points to the zero page.
      #0 0x8135f1f in NullDeref(int*) /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10
      #1 0x8135efa in main /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/null_deref.cpp:21:3
      #2 0x8084be5 in _start (null_deref.cpp.tmp+0x8084be5)

  AddressSanitizer can not provide additional info.
   SUMMARY: AddressSanitizer: SEGV /vol/llvm/src/llvm-project/local/compiler-rt/test/asan/TestCases/null_deref.cpp:15:10 in NullDeref(int*)
  ==29276==ABORTING

I managed to trace this to a change in `<sys/regset.h>`: previously the header would
primarily define the short register indices (like `UESP`). While they are required by the
i386 psABI, they are only required in `<ucontext.h>` and could previously leak into
unsuspecting user code, polluting the namespace and requiring elaborate workarounds
like that in `llvm/include/llvm/Support/Solaris/sys/regset.h`. The change fixed that by restricting
the definition of the short forms appropriately, at the same time defining all `REG_` prefixed
forms for compatiblity with other systems.  This exposed a bug in `compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp`, however:
Previously, the index for the user stack pointer would be hardcoded if `REG_ESP`
wasn't defined. Now with that definition present, it turned out that `REG_ESP` was the wrong index to use: the previous value 17 (and `REG_SP`) corresponds to `REG_UESP`
instead.

With that change, the failures are all gone.

Tested on `amd-pc-solaris2.11`.

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

This adds `EPhOff`, `EPhEntSize` and `EPhNum` keys.
Will be useful for creating broken objects for testing llvm-readelf.

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

This reverts commit 97106f9d.

This is based on feedback from https://reviews.llvm.org/D82988#2147105

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

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