Since GetErrcMessages uses cmake's `try_run` mechanism it's sensitive
to changes to CMAKE_CXX_FLAGS, so we move it into config-ix with the
similar flag-sensitive configuration. This makes it run before
HandleLLVMOptions and avoids issues with LLVM_ENABLE_WERROR and other
configuration that manipulate CMAKE_CXX_FLAGS.

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

Reviewed By: phosek, #libunwind, #libc

Spies: libcxx-commits

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

This patch is to fix some missing lax-vector-conversion warnings including
cases that involve vector bool and vector pixel, also to fix the vector
compatibility check for the warnings.

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

This PR makes flang emit a warning when the user passes an unsupported gfortran warning flag in as a CLI arg.  This PR also checks each `-W` argument instead of just looking at the last one passed in.

Reviewed By: awarzynski

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

This is a generalization of a suggestion from issue #60799
that allows removing a redundant guard of an input value
via icmp+select. It should also solve issue #60801.

This only comes into play for a select with an equality
condition where we are trying to substitute a constant into
the false arm of a select. (A 'true' select arm substitution
allows "refinement", so it is not on this code path.)

The constant must be the same in the compare and the select,
and it must be a "binop absorber" (X op C = C). That query
currently includes 'or', 'and', and 'mul', so there are tests
for all of those opcodes.

We then use "impliesPoison" on the false arm binop and the
original "Op" to be replaced to ensure that the select is not
actually blocking poison from leaking. That could be
potentially expensive as we recursively test each operand, but
it is currently limited to a depth of 2. That's enough to catch
our motivating cases, but probably nothing more complicated
(although that seems unlikely).

I don't know how to generalize a proof for Alive2 for this, but
here's a positive and negative test example to help illustrate
the subtle logic differences of poison/undef propagation:
https://alive2.llvm.org/ce/z/Sz5K-c

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

With this patch freeze undef/poison will no longer be folded into a constant if it's used as a
vector operand in a shufflevector.

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

This patch is to fix some implicit castings for emulated intrinsics
so that there are no lax-vector-conversions errors and warnings.

Reviewed By: nemanjai, #powerpc

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

[Flang] Add user option -funderscoring/-fnounderscoring to control trailing underscore added to external names

This patch adds user option -funderscoring/-fnounderscoring  to control the trailing underscore being appended to external names (e.g. procedure names, common block names). The option in gfortran is documented in https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html.

Reviewed By: clementval

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

Eliminates the sort seems make the whole conversion slower (probably because loop rotation leads to bad locality).

Reviewed By: aartbik

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

No need to swap extractelements, which were not excluded from the list
during cost analysis. It leads to incorrect cost calculation and make
vector code more profitable than it is actually is.

Few existing call-sites have been modified to use LIBC_ASSERT.

Reviewed By: lntue, michaelrj

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

The previous algorithm could order nodes incorrectly, this one strictly
follows the topological order.

This change adds a new spv_undef intrinsic which is emitted in place of
aggregate undef operands and later selected to single OpUndef SPIR-V
instruction. The behavior matches that of Khronos SPIR-V Translator and
should support nested aggregates.

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

As suggested in D140908, make the hasSingleAllocType helper non-static
so that it can be used in other files. Add unit testing.

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

HdrGen CMake build uses TableGen so it should include TableGen module.

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

The default DWARF version without a FreeBSD version specified is 4.

Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179

This patch adds the new pass option `use-opaque-pointers` to the GPU to LLVM lowerings (including ROCD and NVVM) and adapts the code to support using opaque pointers in addition to typed pointers.
The required changes mostly boil down to avoiding `getElementType` and specifying base types in GEP and Alloca.

In the future opaque pointers will be the only supported model, hence tests have been ported to using opaque pointers by default. Additional regression tests for typed-pointers have been added to avoid breaking existing clients.

Note: This does not yet port the `GpuToVulkan` passes.

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

Making the constraint a buildable type makes them incompatible with opaque pointers, at least while we still support typed pointers, since Ops making use of the constraint will then automatically create a typed pointer on parse.

This patch therefore fixes that issue by removing the `BuildableType` mixin. This has a bit of a cascading effect however, as all users of the constraint now need operands of that type to be added to the assembly format, hence a lot of adjustments to the syntax of a lot of (mostly intrinsic) ops.

Few things of note: The syntax as is, is only required while we're supporting both typed and opaque pointers. Once we drop support for typed pointers, we can make it a `BuildableType` again. As a drive by I also fixed the address space not being verified in the constraint. Finally, I added some roundtripping tests, most importantly for ops with `type($specific_operand)` occurences. These are printed incorrectly with typed pointers if not wrapped within a `qualified`.

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

When passing a character with unknown length to a subroutine expecting
an unlimited polymorphic pointer, a new descriptor is created. The
fir.embox operation needs to carry over the length from the character
to be passed correctly.

Reviewed By: PeteSteinfeld

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

Derived-type assignment was already handling the case of derived-type with
allocatable components with the runtime. Extend the code so the polymorphic
allocatable component are also taken into account.

Reviewed By: PeteSteinfeld

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

This reverts commit 75272d5c.

This fails to compile on the clang-debian-cpp20 buildbot:
https://lab.llvm.org/buildbot#builders/249/builds/945.

While looking at other usage of getOSMajorVersion() I noticed if a version number is not
included in the FreeBSD triple it won't include the --hash-style=both linker option or
not disable the use of .init_array. Without a version should be the latest.

FreeBSD 8 and 9 are no longer supported. So simplify things with the version handling
as well.

Reviewed By: dim

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

Add a member function isPPC32SecurePlt() to determine whether Secure
PLT is used by the target 32-bit PowerPC operating environment.

Reviewed By: dim, maskray

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

Summary:
This variable is supposed to control the architectures to build for. At
some point this was changes out for testing and never fixed.

When propagating tensor.unpack ops through elementwise generics, a new
output tensor is needed if the element type of the input differs from
that of the output in the elementwise op.

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

https://reviews.llvm.org/rG8a9d4895df780231a14a1afc44e18b1f6b7eab93

Don't return the number of swaps; it's not used anywhere.

Reviewed By: Mordante, #libc, avogelsgesang

Spies: libcxx-commits

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

The docs currently state that buildbot-worker 2.8.5 is used. However,
looking at the buildbot release notes
<http://docs.buildbot.net/current/relnotes/index.html>, this release
doesn't seem to exist (it's not on PyPI either). The document also links
to http://trac.buildbot.net/ as a source to retrieve an old version and
install it manually, but this is dead.

Instead, drop that advice and suggest pip3 install
buildbot-worker==2.8.4, as done by the Dockerfiles in
llvm-zorg/buildbot/google/docker/*.

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

This makes `append_range` useable with, C arrays and types with custom
`begin`/`end` functions.

Reviewed By: kazu

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

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

At the moment, there is an optional log1pBenefit
populateMathToLibmConversionPatterns which is used to increase the priority of
the log1p->libm pattern compared to log1p->llvm pattern that approximates
log1p with precision issues. Instead, we can have a flag for the MathToLLVM
pass to enable or disable the imprecise approximation.

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

- Do not require both the `Set` and `Element` to be exactly the same type and, instead, only require them to be comparable.
- Do not require `Element` to be copyable.
- Add missing documentation comment.

Reviewed By: beanz

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

issue #60799
issue #60801

Currently clang emits warning with -Wconversion for the following code
on LP64 system e.g. x86_64-unknown-linux-gnu:

long foo(long x) {
  return 1LL<<x;
}
warning: implicit conversion changes signedness: 'long long' to 'long' [-Wsign-conversion]

return 1ll << x;
~~~~~~ ~~~~^~~~
This does not make sense since all operands are signed.

This patch fixes that to match -m32 and GCC behaviour.

Reviewed by: Fangrui Song

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