Reland https://reviews.llvm.org/D158124
Fixed `-fpermissive` error reported by gcc only.

The pre-index matcher just needs some small heuristics to make sure it
doesn't cause regressions. Apart from that it's a simple change, since
the only difference is an immediate operand of '1' vs '0' in the
instruction.

Some textual editing errors got through this pull request that was
merged a few weeks ago: https://github.com/llvm/llvm-project/pull/65876

This patch clears up the unintentional duplicated line, and white-space
at the end of the lines.

I came across those typedefs while working on another change, and I
noticed they were just never used.

If we know that index is larger than SSO size, we know that we can't be
in SSO case, and should access the pointer. This removes extra check
from operator[] for inputs known at compile time to be larger than SSO.

-- In order to compute maximum, we should always initialise the
   result with the largest negative value possible for the concerned
   element type, instead of the smallest.
-- This commit essentially adds a fix to this issue.

Signed-off-by: Abhishek Varma <abhishek@nod-labs.com>

For declarations declared inside a macro, e.g.:
```
`#define MAKE_FUNC(suffix) \
         /// Not selected doc comment \
         void func_##suffix(void) {  }

/// Doc comment foo
MAKE_FUNC(foo)

/// Doc comment bar
MAKE_FUNC(bar)
````

Prefer the doc comment at the expansion site instead of the one defined
in the macro.

rdar://113995729

Since https://github.com/llvm/llvm-project/pull/68052 this has been failing.

https://lab.llvm.org/buildbot/#/builders/219/builds/6545

Follow up changes have not fixed it, XFAIL while I debug it.

These are copies of tests in flang/test/Lower/OpenMP/FIR.

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

linalg::CopyOp is much more generic and useful to promote buffers. In addition, this is linalg transform and makes more sense to use linalg operations when possible.

Currently when building gather/buildvector node, we try to build nodes
shuffles without taking into account separate vector registers. We can
improve final codegen and the whole vectorization process by including
this info into the analysis and the vector code emission, allows to emit
better vectorized code.

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

This reverts commit 560bad01 to fix
a bug reported in https://lab.llvm.org/buildbot/#/builders/5/builds/37763.

Summary:
For the other tests we pass `-nogpulib` to ensure that we set up the
needed libraries correctly. However, this caused problems for the
non-LTO build and test of Nvidia systems. In general this is because we
would do a separate compile of the libomptarget device runtime and then
link in that cubin. This exercised the runtime in a lot of ways it's not
used to, since doing things this way was hardly expected or tested. This
patch disables it only for the Nvidia non-LTO build so that we still get
the effect of `--liboimptarget-nvptx-bc-path` rather than ignoring it.

[libc++][tests] Fix a few remaining instances of outdated static assertion regexes in our test suite

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

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

This is an implementation detail for `move_only_function` (and potentially other type-erasing classes).

Reviewed By: #libc, ldionne

Spies: Mordante, ldionne, EricWF, libcxx-commits

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

This patch refactor said enums to hold total size of a bit-field, and not just non-inherited bits. This brings `Type` and `DeclContext` in line with `Comment` and `Stmt`. It also makes it unnecessary to list all transitive bases of a bit-field as unnamed bit-fields, which makes it more friendly towards debuggers.

```
clang/include/clang/Lex/Preprocessor.h:2893:14: warning: parameter 'isEnter:' not found in the function declaration [-Wdocumentation]
  /// \param isEnter: true if this PP is entering a region; otherwise, this PP
             ^~~~~~~~

clang/include/clang/Lex/Preprocessor.h:2895:14: warning: parameter 'Loc:' not found in the function declaration [-Wdocumentation]
  /// \param Loc: the location of the entry or exit of a
             ^~~~

clang/include/clang/Lex/Preprocessor.h:2907:14: warning: parameter 'StartLoc:' not found in the function declaration [-Wdocumentation]
  /// \param StartLoc: output argument. It will be set to the start location of
             ^~~~~~~~~
```

This patch adds the feature flag FP8 and the assembly/disassembly
for the following instructions of NEON, SVE2 and SME2:
  * NEON Instructions:
    + Advanced SIMD two-register miscellaneous:
      - F1CVTL, F1CVTL2, F2CVTL, F2CVTL2 
      - BF1CVTL, BF1CVTL2, BF2CVTL, BF2CVTL2
    + Advanced SIMD three-register extension:
       - FCVTN, FCVTN2 (FP32 to FP8) 
       - FCVTN (FP16 to FP8)
    + Advanced SIMD three same:
      - FSCALE
  * SVE2 Instructions:
    + Downconvert instructions:
       - FCVTN_Z2Z_HtoB
       - FCVTNB_Z2Z_StoB 
       - BFCVTN_Z2Z_HtoB 
       - FCVTNT_Z2Z_StoB
     + Upconvert instructions:
          - F1CVT_ZZ, F2CVT_ZZ
          - BF1CVT_ZZ, BF2CVT_ZZ
          - F1CVTLT_ZZ, F2CVTLT_ZZ 
          - BF1CVTLT_ZZ, BF2CVTLT_ZZ

  * SME2 Instructions:
    - F1CVT_2ZZ, F2CVT_2ZZ
    - BF1CVT_2ZZ, BF2CVT_2ZZ
    - F1CVTL_2ZZ, F2CVTL_2ZZ
    - BF1CVTL_2ZZ, BF2CVTL_2ZZ
    - FCVT_Z2Z_HtoB, BFCVT_Z2Z_HtoB
    - FCVT_Z4Z - FCVTN_Z4Z
    - FSCALE_2ZZ, FSCALE_4ZZ
    - FSCALE_2Z2Z, FSCALE_4Z4Z

That is according to this documentation:
https://developer.arm.com/documentation/ddi0602/2023-09

I believe this assert was trying to check that 3 variables were equal to
0.

I think it instead got interpreted as ((DSWCount == DSWWithPermCount) ==
DSWWithSharedVMEMCount) == 0 I guess (DSWCount == DSWWithPermCount) was
true because both counts were 0. Then true got compared to
DSWWithSharedVMEMCount, and since DSWWithSharedVMEMCount is 0, that
compare was false. And then that false compared equal to the final 0.

This helped to catch a codegen failure caused by #69703. MachineVerifier
did not complain about this malformed COPY either before regalloc:

  %9:vreg_64 = COPY %17:vgpr_32

Or after regalloc:

  renamable $vgpr0_vgpr1 = COPY renamable $vgpr2, implicit $exec

But we can at least catch the problem when copyPhysReg tries to expand
it into 32-bit register moves and fails to find suitable source
registers:

  $vgpr0 = V_MOV_B32_e32 $noreg, implicit $exec, implicit-def $vgpr0_vgpr1, implicit $vgpr2
  $vgpr1 = V_MOV_B32_e32 $noreg, implicit $exec, implicit $vgpr2, implicit $exec

Also drop phabricator names as we no longer use phabricator.

---------

Co-authored-by: Andy Kaylor <andrew.kaylor@intel.com>

Getting lots of `error: unknown type name 'uint64_t'` and `uint32_t`
in this file on Linux.

Looks like this should work as long as we don't dereference the value.

This is needed for the transform to fire with a correct data layout.
Pre-commiting this change to keep the diff of D141060 smaller.

Add an emitc.for op to the EmitC dialect as a lowering target for
scf.for, replacing its current direct translation to C; The translator
now handles emitc.for instead.

Prep for D148855

Instead of (ab)using incomplete array types for this, add a 'Dummy' bit
to Descriptor. We need to be able to differentiate between the two when
adding an offset.

Static analyze can't report diagnose when statement after a
CXXForRangeStmt and enable widen, because
`ExprEngine::processCFGBlockEntrance` lacks of CXXForRangeStmt and when
`AMgr.options.maxBlockVisitOnPath - 1` equals to `blockCount`, it can't
widen. After next iteration, `BlockCount >=
AMgr.options.maxBlockVisitOnPath` holds and generate a sink node. Add
`CXXForRangeStmt` makes it work.

Co-authored-by: huqizhi <836744285@qq.com>

As explained in `__config`, we have an ABI tag that we use to ensure
that we don't run into ODR issues when mixing different versions of
libc++ in multiple TUs. However, the reasoning behind that extends not
only to different versions of libc++, but also to different
configurations of the same version of libc++. In fact, we've been aware
of this for a while but never really bothered to make the change because
ODR issues are often thought to be benign.

Well, it turns out that I just spent over an hour banging my head
against an issue that boils down to our lack of encoding of some ODR
properties in the ABI tag, so here's the patch we should have done a
long time ago.

For now, the ODR properties we encode in the ABI tag are:
- library version
- exceptions vs no-exceptions
- hardening mode

Those are all things that we support different values for on a per-TU
basis and they definitely affect ODR in a meaningful way. We can add
more properties later as we see fit.

Currently when building gather/buildvector node, we try to build nodes
shuffles without taking into account separate vector registers. We can
improve final codegen and the whole vectorization process by including
this info into the analysis and the vector code emission, allows to emit
better vectorized code.

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