Tests fail on Windows otherwise.

Similar to what SDAG does when it sees a smulo/umulo against 2
(see: `DAGCombiner::visitMULO`)

This pattern is fairly common in Swift code AFAICT.

Here's an example extracted from a Swift testcase:

https://godbolt.org/z/6cT8Mesx7

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

Also, this adds unit tests to check that limits.h complies with the C
standard.

Reviewed By: sivachandra

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

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

bug 51926 identified an issue where a dangling comma caused the cell count to be to off by one

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

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

We weren't retaining the ctypes closures that the ExecutionEngine was
calling back into, leading to mysterious errors.

Open to feedback about how to test this. And an extra pair of eyes to
make sure I caught all the places that need to be aware of this.

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

To avoid using the AST when emitting diagnostics, split the "dontcall"
attribute into "dontcall-warn" and "dontcall-error", and also add the
frontend attribute value as the LLVM attribute value. This gives us all
the information to report diagnostics we need from within the IR (aside
from access to the original source).

One downside is we directly use LLVM's demangler rather than using the
existing Clang diagnostic pretty printing of symbols.

Previous revisions didn't properly declare the new dependencies.

Reviewed By: nickdesaulniers

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

Quantized int type should include I32 types as its the output of a quantizd
convolution or matmul operation.

Reviewed By: NatashaKnk

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

The ARM backend was explicitly setting global binding on the personality
symbol. This was added without any comment in a7ec2dce, which
introduced EHABI support (back in 2011). None of the other backends do
anything equivalent, as far as I can tell.

This causes problems when attempting to wrap the personality symbol.
Wrapped symbols are marked as weak inside LTO to inhibit IPO (see
https://reviews.llvm.org/D33621). When we wrap the personality symbol,
it initially gets weak binding, and then the ARM backend attempts to
change the binding to global, which causes an error in MC because of
attempting to change the binding of a symbol from non-global to global
(the error was added in https://reviews.llvm.org/D90108).

Simply drop the ARM backend's explicit global binding setting to fix
this. This matches all the other backends, and a large internal
application successfully linked and ran with this change, so it
shouldn't cause any problems. Test via LLD, since wrapping is required
to exhibit the issue.

Reviewed By: MaskRay

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

This plugin parses Fortran files and creates a
YAML report with all the OpenMP constructs and
clauses seen in the file.

The following tests have been modified to be
compatible for testing the plugin, hence why
they are not reused from another directory:

- omp-atomic.f90
- omp-declarative-directive.f90
- omp-device-constructs.f90

The plugin outputs a single file in the same
directory as the source file in the following format:
`<source-file-name>.yaml`

Building the plugin:
`ninja flangOmpReport`

Running the plugin:
`./bin/flang-new -fc1 -load lib/flangOmpReport.so -plugin flang-omp-report -fopenmp <source_file.f90>`

Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Stuart Ellis <stuart.ellis@arm.com>

Reviewed By: awarzynski, kiranchandramohan

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

Reviewed By: ezhulenev

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

Reviewed By: ezhulenev

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

This reverts commit 2943071e.

Breaks bots

This reverts commit 952f030f.

Causes bot failures.

Unroll-and-jam currently doesn't work when the loop being unroll-and-jammed
or any of its inner loops has iter_args. This patch modifies the
unroll-and-jam utility to support loops with iter_args.

Reviewed By: bondhugula

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

Instead of using a base class to store the members and the optional
size, use [[no_unique_address]] to achieve the same thing without
needing a base class.

Also, as a fly-by:
- Change subrange from struct to class (per the standard)
- Improve the diagnostic for when one doesn't provide a size to the ctor of a sized subrange
- Replace this->member by just member since it's not in a dependent base anymore

This change would be an ABI break due to [[no_unique_address]], but we
haven't shipped ranges anywhere yet, so this shouldn't affect anyone.

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

Some people downstream are reporting that this test fails. I've been
unable to reproduce, but there is indeed something spooky going on.
Pinning to the new PM suppresses the failure. I'm continuing to
investigate this.

To avoid using the AST when emitting diagnostics, split the "dontcall"
attribute into "dontcall-warn" and "dontcall-error", and also add the
frontend attribute value as the LLVM attribute value. This gives us all
the information to report diagnostics we need from within the IR (aside
from access to the original source).

One downside is we directly use LLVM's demangler rather than using the
existing Clang diagnostic pretty printing of symbols.

Reviewed By: nickdesaulniers

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

Reviewed By: michaelrj

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

This is NFCI (no-functional-change-intended), but there
are benign diffs possible with commutable ops as seen in
the test diffs.

The transforms were repeated for the commutative opcodes,
but that should not be necessary if we canonicalize the
patterns that we're matching. If both operands of the
binop match, that should get folded eventually.

The transform that starts with a mask op seems to
over-constrain the use checks, so that could be a
potential enhancement.

Fix how we calculate the new permutation map of the transfer ops.

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

Also fixes 80-column rule violations.

Before this patch, we had features named 'libc++', 'libstdc++' and
'msvc' to describe the three implementations that use our test suite.
This patch renames them to 'stdlib=libc++', 'stdlib=libstdc++', etc
to avoid confusion between MSVC's STL and the MSVC compiler (or Clang
in MSVC mode).

Furthermore, this prepares the terrain for adding support for additional
"implementations" to the test suite. Basically, I'd like to be able to
treat Apple's libc++ differently from LLVM's libc++ for the purpose of
testing, because those effectively behave in different ways in some aspects.

Make it more generic by accepting weak_odr and dso_local specifiers.

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

This reverts commit f6954bf8.

This breaks the test-suite O3 build:

/home/nikic/llvm-test-suite/build-O3/tools/timeit --summary Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/local_laplacian.bc.o.time /home/nikic/llvm-project/build/bin/clang++  -DNDEBUG  -O3   -w -Werror=date-time -save-stats=obj -save-stats=obj -std=c++11 -MD -MT Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/local_laplacian.bc.o -MF Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/local_laplacian.bc.o.d -o Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/local_laplacian.bc.o -c ../Bitcode/Benchmarks/Halide/local_laplacian/local_laplacian.bc
While deleting: i64 %
Use still stuck around after Def is destroyed:  %12620 = mul i64 %12619, <badref>
clang++: /home/nikic/llvm-project/llvm/lib/IR/Value.cpp:103: llvm::Value::~Value(): Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed.

Function profile counts added to test cases. Regenerated test lines for
loop predication test.

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

(This is a recommit of 3d6f49a5 that should no longer break validation since
bd379915).

It is a common practice in glibc header to provide an inline redefinition of an
existing function. It is especially the case for fortified function.

Clang currently has an imperfect approach to the problem, using a combination of
trivially recursive function detection and noinline attribute.

Simplify the logic by suffixing these functions by `.inline` during codegen, so
that they are not recognized as builtin by llvm.

After that patch, clang passes all tests from https://github.com/serge-sans-paille/fortify-test-suite

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

Some tests with binary IDs would fail with error: no profile can be merged.
This is because raw profiles could have unaligned headers when emitting binary
IDs. This means padding should be emitted after binary IDs are emitted to
ensure everything else is aligned. This patch adds padding after each binary ID
to ensure the next binary ID size is 8-byte aligned. This also adds extra
checks to ensure we aren't reading corrupted data when printing binary IDs.

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

This reverts commit c0687e19.

There are testing failures being caught by bots.
See http://45.33.8.238/linux/56886/step_8.txt as an example.

This reverts commit 3d6f49a5.

Broke bot: https://lab.llvm.org/buildbot/#/builders/5/builds/12360

This allows clang to work on Linux distributions like Debian where
<CUDA-PATH>/include may be a symlink to /usr/include. We only need
`cuda_wrappers` to be present before the standard C++ library headers.
The CUDA SDK headers themselves do not need to be found that early.

This addresses https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995122
mentioned in post-commit comments on D108247

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

Reviewed By: michaelrj

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

multiplication

The following code modifies elements of the array D.

    for (i = 0; i < _PB_NI; i++)
      for (j = 0; j < _PB_NJ; j++)
      {
        for (k = 0; k < _PB_NK; k++)
        {
          double Mul = A[i][k] * B[k][j];
          D[i][j][k] += Mul;
          C[i][j] += Mul;
        }
      }

Nevertheless, the code is recognised as a matrix-matrix multiplication, since
the second and third dimensions of D are accessed with non-zero strides.

This fixes the typo, which was made during the translation to C++ bindings
(https://reviews.llvm.org/D35845).

Reviewed By: Michael Kruse <llvm@meinersbur.de>

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