This patch should fix the build failure that surfaced when build llvm
with GCC: https://lab.llvm.org/staging/#/builders/16/builds/10450



GCC complained that I explicitely specialized
 `ScriptedPythonInterface::ExtractValueFromPythonObject` in a
in non-namespace scope, which is tolerated by Clang.

To solve this issue, the specialization were declared out of the class
and implemented in the source file.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

This makes the IR more readable, in particular when this will be used on
the builtin func outside of the LLVM dialect.

Reviewed By: wsmoses

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

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

The preprocessor definitions __BYTE_ORDER__, __ORDER_BIG_ENDIAN__, and
__ORDER_LITTLE_ENDIAN__ are gcc extensions (also supported by clang),
but msvc (and others) do not define them. As a result __BYTE_ORDER__
and __ORDER_BIG_ENDIAN__ both evaluate to 0 by the prepreprocessor,
and __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__, the first `#if` condition
to 1, hence assuming the wrong byte order for x86(_64).

This patch instead uses CMake's TestBigEndian module to determine
target architecture's endianness at configure-time.

Note this also uses the same mechanism for the runtime. If compiling
flang as a cross-compiler, the runtime for the compile-target must be
built separately (Flang does not support the LLVM_ENABLE_RUNTIMES
mechanism yet).

Fixes llvm.org/PR51597

Reviewed By: ijan1, Leporacanthicus

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

Fix edge case where "0x" would be considered a complete hexadecimal
number for purposes of str_end. Now the hexadecimal prefix needs a valid
digit after it, else just the 0 will be counted as the number.

Reviewed By: sivachandra

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

This simplifies setting up sparse tensors through C-style data structures.
Useful for runtimes that want to interact with MLIR-generated code
without knowning about all bufferization details (viz. memrefs).

Reviewed By: bixia

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

The test driver-fopenmp-extensions.c is failing on platforms that does
not use integrated-as. It can be reproduced using -fno-integrated-as on
Linux too.

bin/clang -c -Xclang -verify=omp -fopenmp      -fopenmp-extensions
-fno-openmp-extensions
../llvm-project/clang/test/OpenMP/driver-fopenmp-extensions.c
-fno-integrated-as
Assembler messages:
Error: can't open /tmp/driver-fopenmp-extensions-8fafe8.s for reading:
No such file or directory
clang-14: error: assembler command failed with exit code 1 (use -v to
see invocation)

The goal of this test is to verify syntax diags only,
so we should use clang_cc1 to test.

Reviewed By: jdenny, ABataev

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

Follow up to 2cbd3b04 which added
support for unnamed images but missed the use case in parse_frames.

Those constructors are very easy to misuse -- one could easily think that
the size passed to the constructor is the size of the range to exhibit
from the subrange. Instead, it's a size hint and it's UB to get it wrong.
Hence, when it's cheap to compute the real size of the range, it's cheap
to make sure that the user didn't get it wrong.

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

This reverts commit 2fbd254a, which broke the libc++ CI. I'm reverting
to get things stable again until we've figured out a way forward.

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

This does add some extra superfluous whitespace (eg: "int *") intended
to make the Simplified Template Names work easier - this makes the
DIE-based names match more exactly the clang-generated names, so it's
easier to identify cases that don't generate matching names.

(arguably we could change clang to skip that whitespace or add some
fuzzy matching to accommodate differences in certain whitespace - but
this seemed easier and fairly low-impact)

Make the dtor virtual to fix the warning.

[libc++][NFC] Mark values in gdb pretty print comparison functions as live to prevent values being optimized out.

It appears when testing LLVM 13 on Power, we run into failures with the
`libcxx/test/libcxx/gdb/gdb_pretty_printer_test.sh.cpp` test case optimizing
values out.

Despite some the functions in the test already being marked with optnone,
adding the `MarkAsLive()` calls inside of the pretty printer comparison functions
resolves the issues of the values being optimized out.

This patch aims to address https://llvm.org/PR51675.

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

This generalizes the examples shown in:
https://llvm.org/PR51566

https://alive2.llvm.org/ce/z/V-sEy9

We've been seeing this test return 31 instead of 32 for the "functions"
line in this test on our AArch64 bots.

One possible cause is some of the children not finishing in time
before the llvm-profdata commands are run, if the machine is heavily loaded.

Wait for all the children to finish before exiting the parent.

Reviewed By: zequanwu

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

See PR51708.

Attempting copy elision in dependent contexts with invalid variable,
such as a variable with incomplete type, would cause a crash when attempting
to calculate it's alignment.

The fix is to just skip this optimization on invalid VarDecl, as otherwise this
provides no benefit to error recovery: This functionality does not try to
diagnose anything, it only calculates a flag which will affect where the
variable will be allocated during codegen.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: rtrieu

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

_LIBCPP_HAS_NO_LONG_LONG was only defined on FreeBSD. Instead, use the
using_if_exists attribute to skip over declarations that are not available
on the base system. Note that there's an annoying limitation that we can't
conditionally define a function based on whether the base system provides
a function, so for example we still need preprocessor logic to define the
abs() and div() overloads.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675 has now been resolved
in GCC 11, so we can remove those workarounds.

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

As an extension to D107866, this adds store(fptosisat(..)) patterns,
similar to the existing fptosi patterns, to prevent unnecessarily moving
into gpr regs where we can use fp stores directly.

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

Ran `git ls-files '*.gn' '*.gni' | xargs llvm/utils/gn/gn.py format`.

The file is requiring x86, but using llc without triple.

This will cause problem on non-x86 platforms, as the default triple will
not be x86.

eg: On PowerPC le, it will emit warnings as:

'x86-64' is not a recognized processor for this target (ignoring
processor)
'+cx8' is not a recognized feature for this target (ignoring feature)
'+fxsr' is not a recognized feature for this target (ignoring feature)
'+mmx' is not a recognized feature for this target (ignoring feature)
'+sse' is not a recognized feature for this target (ignoring feature)
..

On some other platform, it may even crash -- if some of the feature are
with same name (eg: soft-float).

Add the triple as this was the intention test target.

Per the comments, `hash_code` values "are not stable to save or
persist", so are unsuitable for the module hash, which must persist
across compilations for the implicit module hashes to match. Note that
in practice, today, `hash_code` are stable. But this is an
implementation detail, with a clear `FIXME` indicating we should switch
to a per-execution seed.

The stability of `MD5` also allows modules cross-compilation use-cases.
The `size_t` underlying storage for `hash_code` varying across platforms
could cause mismatching hashes when cross-compiling from a 64bit
target to a 32bit target.

Note that native endianness is still used for the hash computation. So hashes
will differ between platforms of different endianness.

Reviewed By: jansvoboda11

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

Move the closure of the subset of flang/runtime/*.h header files that
are referenced by source files outside flang/runtime (apart from unit tests)
into a new directory (flang/include/flang/Runtime) so that relative
include paths into ../runtime need not be used.

flang/runtime/pgmath.h.inc is moved to flang/include/flang/Evaluate;
it's not used by the runtime.

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

On some platform (eg: AIX), diff will complain about newline.

diff: Missing newline at the end of file
.../llvm/test/tools/llvm-profdata/Inputs/cs-sample.proftext.

This patch splits the previous `ScriptedProcessPythonInterface` into
multiple specific classes:

1. The `ScriptedInterface` abstract class that carries the interface
   instance object and its virtual pure abstract creation method.

2. The `ScriptedPythonInterface` that holds a generic `Dispatch` method that
   can be used by various interfaces to call python methods and also keeps a
   reference to the Python Script Interpreter instance.

3. The `ScriptedProcessInterface` that describes the base Scripted
   Process model with all the methods used in the underlying script.

All these components are used to refactor the `ScriptedProcessPythonInterface`
class, making it more modular.

This patch is also a requirement for the upcoming work on `ScriptedThread`.

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



Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Revert "[analyzer][NFCI] Allow clients of NoStateChangeFuncVisitor to check entire function calls, rather than each ExplodedNode in it"

This reverts commit a375bfb5.

This was causing a bot to crash:

https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/23380/

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

This extends D107865 to the VFP insructions, lowering llvm.fptosi.sat
and llvm.fptoui.sat to VCVT instructions that inherently perform the
saturate.

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

We end up calling resolveBranchVA(), which asserts for Undefineds.

As fix, just return early in Writer::run() if there are any diagnostics
after processing relocations (which is where undefined symbol errors are
emitted). This matches what the ELF port does.

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

This patch changes the register class to avoid accidentally setting
the AVL operand to X0 through MachineIR optimizations.

There are cases where we really want to use X0, but we can't get that
past the MachineVerifier with the register class as GPRNoX0. So I've
use a 64-bit -1 as a sentinel for X0. All other immediate values should
be uimm5. I convert it to X0 at the earliest possible point in the VSETVLI
insertion pass to avoid touching the rest of the algorithm. In
SelectionDAG lowering I'm using a -1 TargetConstant to hide it from
instruction selection and treat it differently than if the user
used -1. A user -1 should be selected to a register since it doesn't
fit in uimm5.

This is the rest of the changes started in D109110. As mentioned there,
I don't have a failing test from MachineIR optimizations anymore.

Reviewed By: frasercrmck

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

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

This is a pretty small bit of CMake goop to generate code coverage
reports. I always forget the right script invocation and end up
fumbling around too much.

Wouldn't it be great to have targets that "Just Work"?

Well, I thought so.

At present this only really works correctly for LLVM, but I'll extend
it in subsequent patches to work for subprojects.

Reviewed By: phosek

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