We're testing the parsing behavior, not the actual attributes used, and
the attribute name cannot be elided for __declspec attributes.

With D92696, the Scudo Standalone GWP-ASan flag parsing was changed to
the new GWP-ASan optional one. We do not necessarily want this, as this
duplicates flag parsing code in Scudo Standalone when using the
GWP-ASan integration.

This CL reverts the changes within Scudo Standalone, and increases
`MaxFlags` to 20 as an addionnal option got us to the current max.

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

These changes are intended to give code a path to move away from the GNU
,##__VA_ARGS__ extension, which is non-conforming in some situations and
which we'd like to disable in our conforming mode in those cases.

In Clang today, we parse the different attribute syntaxes
(__attribute__, __declspec, and [[]]) in a fairly rigid order. This
leads to confusion for users when they guess the order incorrectly,
and leads to bug reports like PR24559 or necessitates changes like
D94788.

This patch adds a helper function to allow us to more easily parse
attributes in arbitrary order, and then updates all of the places
where we would parse two or more different syntaxes in a rigid order to
use the helper method. The patch does not attempt to handle Microsoft
attributes ([]) because those are ambiguous with other code constructs
and we don't have any attributes that use the syntax.

When OMP_PLACES contains an invalid value, the warning informs the user
that the fallback is OMP_PLACES=threads, but the actual internal setting
is OMP_PLACES=cores and is detected as such with KMP_SETTINGS=1.
This patch informs the user that OMP_PLACES=cores is being used instead
of OMP_PLACES=threads.

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

This patch adds the new algorithm for topology discovery using cpuid
leaf 1f.  Only the new die level is detected and integrated into the
current affinity mechanisms including KMP_AFFINITY (granularity level
and compact/scatter algorithm), OMP_PLACES=dies, and KMP_HW_SUBSET.

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

HWLOC 2.0 has numa nodes as separate children and are not in the main
parent/child topology tree anymore.  This change takes this into
account.  The main topology detection loop in the create_hwloc_map()
routine starts at a hardware thread within the initial affinity mask and
goes up the topology tree setting the socket/core/thread labels
correctly.

This change also introduces some of the more generic changes that the
future kmp_topology_t structure will take advantage of including a
generic ratio & count array (finding all ratios of topology layers like
threads/core cores/socket and finding all counts of each topology
layer), generic radix1 reduction step, generic uniformity check, and
generic printing of topology (en_US.txt)

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

-Remove the ISD opcode for READ_VL. Just emit the MachineSDNode directly.
-Move segmented fault first only load intrinsic handling completely to
 RISCVISelDAGToDAG.cpp and emit the ReadVL MachineSDNode there
 instead of lowering to ISD opcodes first.

Strangely int_lib.h only includes stdint.h and not stddef.h, so we need
to include the latter to be able to use size_t here.

This fixes the implementation for architectures like CHERI with strong
pointer provenance (pointers, and thus uintptr_t, are represented as
hardware capabilities). Specifically, adding two uintptr_t's together
(as is done for `start + length` and `funcStart + landingPad`) has
ambiguous provenance, whereas using a plain integer (such as size_t) for
the offset operand does not. Also, readULEB128 is creating a plain
integer, not a pointer.

On all currently-supported architectures this should be an NFC, as
size_t and uintptr_t end up being the same underlying plain integer
type.

Reviewed By: MaskRay

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

I am trying to untangle the fast-math-flags propagation logic
in the vectorizers (see a6f02212 for SLP).

The loop vectorizer has a mix of checking FP function attributes,
IR-level FMF, and just wrong assumptions.

I am trying to avoid regressions while fixing this, and I think
the IR-level logic is good enough for that, but it's hard to say
for sure. This would be the 1st step in the clean-up.

The existing test that I changed to include 'fast' actually shows
a miscompile: the function only had the equivalent of nnan, but we
created new instructions that had fast (all FMF set). This is
similar to the example in https://llvm.org/PR35538

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

The `zx_vmar_op_range` allows us to decommit memory pages without
needing a handle to the underlying vmo, as long as we have a handle to
a vmar that contains this mapping. This allows us to implement the
`ReleaseMemoryPagesToOS` function by decommitting the memory using a
handle to the root vmar.

Reviewed By: mcgrathr

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

Use an enum to more explicitly represent the test execution order.

This reverts commit f4537935.
This reverts commit b43c26d0.

This GNU and MSVC extension turns out to be very popular. Most projects
are not using C++20, so cannot use the new __VA_OPT__ feature to be
standards conformant. The other workaround, using -std=gnu*, enables too
many language extensions and isn't viable.

Until there is a way for users to get the behavior provided by the
`, ## __VA_ARGS__` extension in the -std=c++17 and earlier language
modes, we need to revert this.

Imported functions and variable get the visibility from the module supplying the
definition.  However, non-imported definitions do not get the visibility from
(ELF) the most constraining visibility among all modules (Mach-O) the visibility
of the prevailing definition.

This patch

* adds visibility bits to GlobalValueSummary::GVFlags
* computes the result visibility and propagates it to all definitions

Protected/hidden can imply dso_local which can enable some optimizations (this
is stronger than GVFlags::DSOLocal because the implied dso_local can be
leveraged for ELF -shared while default visibility dso_local has to be cleared
for ELF -shared).

Note: we don't have summaries for declarations, so for ELF if a declaration has
the most constraining visibility, the result visibility may not be that one.

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

[FaultsMaps][llvm-objdump] Move FaultMapParser to Object/. Remove CodeGen dependency from llvm-objdump

FaultsMapParser lived in CodeGen and was forcing llvm-objdump to
link CodeGen and everything CodeGen depends on.

This was previously attempted in r240364 to fix a link failure.
The CodeGen dependency was independently added to fix the same
link failure, and that ended up being kept.

Removing the dependency seems like the correct layering for
llvm-objdump.

Reviewed By: MaskRay, jhenderson

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

The added comment explains why it has been disabled for now. We will
enable back when we fix the problem.

[RISCV] Group the legal vector types into lists we can iterator over in the RISCVISelLowering constructor

Remove the RISCVVMVTs namespace because I don't think it provides
a lot of value. If we change the mappings we'd likely have to add
or remove things from the list anyway.

Add a wrapper around addRegisterClass that can determine the
register class from the fixed size of the type.

Reviewed By: frasercrmck, rogfer01

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

kernels loop and enter data had a too restrictive constraint for the wait clause.
The wait clause is allowed multiple times and not only once. This patch fix this problem.

Reviewed By: SouraVX

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

See https://reviews.llvm.org/D94718#2521489 for details.

This gives the user control over which expander to use, which in turn
allows the user to decide what to do with the expanded instructions.

Used in D75980.

Reviewed By: lebedev.ri

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

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

Add a test for the backend.

Avoid unnecessary copies. Reported by clang-tidy.

Ensure namespace braces have the correct comment with them

Use auto pointer/reference to fix llvm-qualified-auto remarks.

While this is mostly NFC right now, because only ARM happens
to run this pass with DomTree available before it,
and required after it, more backends will be affected once
the SimplifyCFG's switch for domtree preservation is flipped,
and DwarfEHPrepare also preserves the domtree.

We already ask for it, so it might be good to ensure that it is
actually initialized before us. Doesn't seem to matter in practice though.

FreeBSD uses -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface to
poison uses of floating point in its standalone environment. It also
deprecates machine/limits.h in favour of sys/limits.h and does not even
provide the former on newer architectures.

This is a cleaner reimplementation of equivalent patches in FreeBSD's
vendored copy of compiler-rt.

Reviewed By: dim

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

Now the only ones we're still missing from P0879
are `sort` and `nth_element`.

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

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

https://reviews.llvm.org/rG5369517d20dd362a178a1b2d6c398d8898ee4620
bumped the version number in __config to 13000, causing a test failure
in libcxx/test/libcxx/libcpp_version.pass.cpp because now the two
don't match.

This is the only part of the post-release TODO in
libcxx/docs/Contributing.rst that wasn't done by that commit.

Restriction on clauses for the EXIT DATA directive were not fully correct.
This patch fixes the situation. The async, if and finalize clauses are allowed
only once.

Reviewed By: SouraVX

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

Restriction on clauses for the HOST_DATA directive were not fully correct.
This patch fixes the situation. The if and if_present clauses are allowed
only once.

Reviewed By: SouraVX

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