Commit Graph

225 Commits

Author SHA1 Message Date
Piotr Kubaj
a1ffc2fe9c llvm: make sure to use ELFv2 ABI on powerpc64
Currently LLVM is more or less set up to use ELFv2, but it still defaults to
ELFv1 in some places. This causes lld to generate broken binaries when used
with LTO.

PR:	269455
Approved by:	dim
MFC after:	3 days
2023-02-17 00:53:30 +01:00
Dimitry Andric
4378cc5cfb Reapply: <type_traits>: Avoid instantiating a pointer type in std::decay<>
GCC expands the pointer type in this conditional expression even for
  template types _Up that are not arrays.  This raises an error when
  std::decay<> is used with reference types (as is done in LLVM's
  sources).  Using add_pointer<> causes GCC to only instantiate a
  pointer type for array types.

  A similar change to this commit (albeit reworked due to upstream
  changes) has been merged to libc++ in commit
  26068c6e60324ed866a1ca2afb5cb5eb0aaf015b.

  In file included from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/ordering.h:13,
                   from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/common_comparison_category.h:12,
                   from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/tuple:168,
                   from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20,
                   from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17,
                   from /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:36:
  /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits: In instantiation of 'struct std::__1::__decay<llvm::CHIArg&, true>':
  /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1591:89:   required from 'struct std::__1::decay<llvm::CHIArg&&>'
  /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__utility/pair.h:132:16:   required by substitution of 'template<class _Tuple, typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> > constexpr std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::pair(_Tuple&&) [with _Tuple = llvm::CHIArg&&; typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> = <missing>]'
  /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:892:51:   required from here
  /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1582:30: error: forming pointer to reference type 'std::__1::remove_extent<llvm::CHIArg&>::type' {aka 'llvm::CHIArg&'}
   1582 |                      >::type type;
        |                              ^~~~

  Reviewed by:    dim
  Differential Revision:  https://reviews.freebsd.org/D36898

This reapplies commit c36de97088, which I
accidentally overwrote in the llvm 15 merge. (It turns out upstream did
not merge this to their 15.x branch.)

MFC after:	2 weeks
2023-02-09 17:28:32 +01:00
Dimitry Andric
50d7464c3f Merge llvm-project release/15.x llvmorg-15.0.7-0-g8dfdcc7b7bf6
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.7-0-g8dfdcc7b7bf6.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:05:25 +01:00
Dimitry Andric
f3fd488f1e Merge llvm-project release/15.x llvmorg-15.0.6-0-g088f33605d8a
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.6-0-g088f33605d8a.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:05:19 +01:00
Dimitry Andric
6246ae0b85 Merge llvm-project release/15.x llvmorg-15.0.2-10-gf3c5289e7846
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.2-10-gf3c5289e7846.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:05:09 +01:00
Dimitry Andric
a4a491e223 Merge llvm-project release/15.x llvmorg-15.0.0-9-g1c73596d3454
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.0-9-g1c73596d3454.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:05:02 +01:00
Dimitry Andric
61cfbce334 Merge llvm-project release/15.x llvmorg-15.0.0-rc2-40-gfbd2950d8d0d
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15.0.0-rc2-40-gfbd2950d8d0d.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:04:56 +01:00
Dimitry Andric
972a253a57 Merge llvm-project main llvmorg-15-init-17826-g1f8ae9d7e7e4
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17826-g1f8ae9d7e7e4, the last commit before
the upstream release/16.x branch was created.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:04:48 +01:00
Dimitry Andric
fcaf7f8644 Merge llvm-project main llvmorg-15-init-17485-ga3e38b4a206b
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17485-ga3e38b4a206b.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:04:38 +01:00
Dimitry Andric
753f127f3a Merge llvm-project main llvmorg-15-init-16436-g18a6ab5b8d1f
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-16436-g18a6ab5b8d1f.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:03:59 +01:00
Dimitry Andric
81ad626541 Merge llvm-project main llvmorg-15-init-15358-g53dc0f10787
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-15358-g53dc0f10787.

PR:		265425
MFC after:	2 weeks
2023-02-08 20:02:26 +01:00
Konstantin Belousov
4c4a29267c libcxx: add comment explaining why umtx is only used for 64bits
Requested by:	imp
Reviewed by:	arichardson, emaste
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D38178
2023-01-25 03:19:42 +02:00
Konstantin Belousov
25b18d8935 libcxx: use __SIZEOF_LONG__ == 8 instead of __LP64__
for CHERI.

Requested by:	arichardson
Reviewed by:	arichardson, emaste, imp
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D38178
2023-01-25 03:19:27 +02:00
Konstantin Belousov
9c996882b0 libcxx: Implement atomic::wait/notify using _umtx_op(2) for 64bit arches
Only 64bit architectures can be supported this way, because libcxx
defines __cxx_contention_t to be int64_t for FreeBSD, and 32bit arches
do not have a kind of UMTX_OP_WAIT_INT64_PRIVATE operation.

LLVM review:	https://reviews.llvm.org/D142134

Tested by:	emaste
Reviewed by:	dim, emaste, markj
Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D38132
2023-01-24 02:52:42 +02:00
Dimitry Andric
4589169768 Apply llvm fix for crash building julia on PowerPC64
Merge commit 6710b21d4698 from llvm git (by Kai Luo):

  [PowerPC] Allow llvm.ppc.cfence to accept pointer types

  In the context of atomic load, integer, pointer and float point types are allowed, thus we should allow llvm.ppc.cfence to accept any type mentioned.

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

  Reviewed By: shchenz, vchuravy

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

Requested by:	jhibbits
MFC after:	3 days
2022-12-16 14:28:10 +01:00
John Baldwin
c36de97088 <type_traits>: Avoid instantiating a pointer type in std::decay<>.
GCC expands the pointer type in this conditional expression even for
template types _Up that are not arrays.  This raises an error when
std::decay<> is used with reference types (as is done in LLVM's
sources).  Using add_pointer<> causes GCC to only instantiate a
pointer type for array types.

A similar change to this commit (albeit reworked due to upstream
changes) has been merged to libc++ in commit
26068c6e60324ed866a1ca2afb5cb5eb0aaf015b.

In file included from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/ordering.h:13,
                 from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/common_comparison_category.h:12,
                 from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/tuple:168,
                 from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20,
                 from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17,
                 from /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:36:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits: In instantiation of 'struct std::__1::__decay<llvm::CHIArg&, true>':
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1591:89:   required from 'struct std::__1::decay<llvm::CHIArg&&>'
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__utility/pair.h:132:16:   required by substitution of 'template<class _Tuple, typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> > constexpr std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::pair(_Tuple&&) [with _Tuple = llvm::CHIArg&&; typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> = <missing>]'
/usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:892:51:   required from here
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1582:30: error: forming pointer to reference type 'std::__1::remove_extent<llvm::CHIArg&>::type' {aka 'llvm::CHIArg&'}
 1582 |                      >::type type;
      |                              ^~~~

Reviewed by:	dim
Differential Revision:	https://reviews.freebsd.org/D36898
2022-11-23 16:10:05 -08:00
Ed Maste
9c231325e7 Clang: Add Diags for targets pre to i686 for -fcf-protection
Intel Control-flow Enforcement Technology (CET) provides new
instructions `endbr32/64` for the indirect branch control.
They are NOPs on i686 and new targets.  We need to check for that
in case it crashes on older targets.

PR:		264497
Reviewed by:	dim
MFC after:	1 week
Obtained from:	LLVM commit 52516782972730ff065a34123a9d8876da08c254
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D37268
2022-11-04 20:42:26 -04:00
Dimitry Andric
91ec809f0a Apply llvm fix for assertion/crash building math/vtk
Merge commit 307ace7f20d5 from llvm git (by David Sherwood):

  [LoopVectorize] Ensure the VPReductionRecipe is placed after all it's inputs

  When vectorising ordered reductions we call a function
  LoopVectorizationPlanner::adjustRecipesForReductions to replace the
  existing VPWidenRecipe for the fadd instruction with a new
  VPReductionRecipe. We attempt to insert the new recipe in the same
  place, but this is wrong because createBlockInMask may have
  generated new recipes that VPReductionRecipe now depends upon. I
  have changed the insertion code to append the recipe to the
  VPBasicBlock instead.

  Added a new RUN with tail-folding enabled to the existing test:

    Transforms/LoopVectorize/AArch64/scalable-strict-fadd.ll

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

Reported by:	yuri
PR:		264834
MFC after:	3 days
2022-09-27 23:45:56 +02:00
Dimitry Andric
9ef1127008 Apply tentative llvm fix for avoiding fma on PowerPC SPE
Merge llvm review D77558, by Justin Hibbits:

  PowerPC: Don't hoist float multiply + add to fused operation on SPE

  SPE doesn't have a fmadd instruction, so don't bother hoisting a
  multiply and add sequence to this, as it'd become just a library call.
  Hoisting happens too late for the CTR usability test to veto using the CTR
  in a loop, and results in an assert "Invalid PPC CTR loop!".

Reported by:		alfredo
Obtained from:		https://reviews.llvm.org/D77558
MFC after:		3 days
2022-07-09 15:17:26 +02:00
Dimitry Andric
3b7f365e4d Apply clang fix for assertion building llvm with libc++ 15
Merge commit f1b0a4fc540f from llvm git (by Richard Smith):

  An expression should only contain an unexpanded parameter pack if it
  lexically contains a mention of the pack.

  Systematically distinguish between syntactic and semantic references to
  packs, especially when propagating dependence from a type into an
  expression. We should consult the type-as-written when computing
  syntactic dependence and should consult the semantic type when computing
  semantic dependence.

  Fixes #54402.

MFC after:	3 days
2022-07-03 21:33:22 +02:00
Dimitry Andric
836d47d38e Apply llvm fix for assertion/crash building archivers/c-blosc2
Merge commit 88ce403c6aab from llvm git (by Florian Hahn):

  [LV] Add new block to place recurrence splice, if needed.

  In some cases, a recurrence splice instructions needs to be inserted
  between to regions, for example if the regions get re-arranged during
  sinking.

  Fixes #56146.

PR:		264979
Reported by:	Robert Clausecker <fuz@fuz.su>
MFC after:	3 days
2022-07-02 01:13:46 +02:00
Dimitry Andric
56f451bb3b Merge llvm-project release/14.x llvmorg-14.0.5-0-gc12386ae247c
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.5-0-gc12386ae247c, aka 14.0.5 release.

PR:		261742
MFC after:	3 days
2022-06-12 20:53:16 +02:00
Dimitry Andric
2a66634d1b Merge llvm-project release/14.x llvmorg-14.0.4-0-g29f1039a7285
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.4-0-g29f1039a7285, aka 14.0.4 release.

PR:		261742
MFC after:	3 days
2022-06-04 15:18:46 +02:00
Dimitry Andric
592e876a42 Apply llvm fix for possible hangs with CPUTYPE=skylake-avx512
Merge commit e8305c0b8f49 from llvm git (by Simon Pilgrim)

    [X86] combineX86ShuffleChain - don't fold to truncate(concat(V1,V2)) if it was already a PACK op

    Fixes #55050

PR:		264394
Reported by:	VVD <vvd@unislabs.com>
MFC after:	3 days
2022-06-01 23:45:59 +02:00
Dimitry Andric
cfefd16d57 Apply compiler-rt fix for building with earlier versions of clang
Merge commit 18efa420da5f from llvm git (by Brooks Davis)

  compiler-rt: Allow build without __c11_atomic_fetch_nand

  Don't build atomic fetch nand libcall functions when the required
  compiler builtin isn't available. Without this compiler-rt can't be
  built with LLVM 13 or earlier.

  Not building the libcall functions isn't optimal, but aligns with the
  usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM
  13 clang and no LLVM 14 clang is built.

  Reviewed By:	  efriedma

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

MFC after:	3 days
2022-06-01 20:29:15 +02:00
Dimitry Andric
6a5eebc190 Apply clang fix for assertion failure building putty 0.77 on i386
Merge commit 45084eab5e63 from llvm git (by Arthur Eubanks):

  [clang] Fix some clang->llvm type cache invalidation issues

  Take the following as an example

    struct z {
      z (*p)();
    };

    z f();

  When we attempt to get the LLVM type of f, we recurse into z. z itself
  has a function pointer with the same type as f. Given the recursion,
  Clang simply treats z::p as a pointer to an empty struct `{}*`. The
  LLVM type of f is as expected. So we have two different potential
  LLVM types for a given Clang type. If we store one of those into the
  cache, when we access the cache with a different context (e.g. we
  are/aren't recursing on z) we may get an incorrect result. There is some
  attempt to clear the cache in these cases, but it doesn't seem to handle
  all cases.

  This change makes it so we only use the cache when we are not in any
  sort of function context, i.e. `noRecordsBeingLaidOut() &&
  FunctionsBeingProcessed.empty()`, which are the cases where we may
  decide to choose a different LLVM type for a given Clang type. LLVM
  types for builtin types are never recursive so they're always ok.

  This allows us to clear the type cache less often (as seen with the
  removal of one of the calls to `TypeCache.clear()`). We
  still need to clear it when we use a placeholder type then replace it
  later with the final type and other dependent types need to be
  recalculated.

  I've added a check that the cached type matches what we compute. It
  triggered in this test case without the fix. It's currently not
  check-clang clean so it's not on by default for something like expensive
  checks builds.

  This change uncovered another issue where the LLVM types for an argument
  and its local temporary don't match. For example in type-cache-3, when
  expanding z::dc's argument into a temporary alloca, we ConvertType() the
  type of z::p which is `void ({}*)*`, which doesn't match the alloca GEP
  type of `{}*`.

  No noticeable compile time changes:
  https://llvm-compile-time-tracker.com/compare.php?from=3918dd6b8acf8c5886b9921138312d1c638b2937&to=50bdec9836ed40e38ece0657f3058e730adffc4c&stat=instructions

  Fixes #53465.

  Reviewed By: rnk

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

PR:		264318
Reported by:	mandree
MFC after:	3 days
2022-05-28 23:26:37 +02:00
Dimitry Andric
eca6e0f7e4 Apply clang fix for assertion failure building webkit2-gtk
Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

  PR45879: Fix assert when constant evaluating union assignment.

  Consider the form of the first operand of a class assignment not the
  second operand when implicitly starting the lifetimes of union members.
  Also add a missing check that the assignment call actually came from a
  syntactic assignment, not from a direct call to `operator=`.

PR:		264280
Reported by:	bapt
MFC after:	3 days
2022-05-27 19:44:06 +02:00
Dimitry Andric
1a0329799c Apply llvm fix for "Invalid PPC CTR loop!" error on powerpcspe
Merge commit d9d15af7873f from llvm git (Qiu Chaofan):

  [PowerPC] Treat llvm.fmuladd intrinsic as using CTR

  This fixes bug 55463, similar to D78668. This is a temporary fix since
  we will switch to post-isel CTR loop determination in the future.

  Reviewed By: dim, shchenz

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

MFC after:	2 weeks
2022-05-18 20:29:02 +02:00
Piotr Kubaj
f5024381ac powerpc: enable supported sanitizers on powerpc64*
1. Merge LLVM's 315d792130258a9b7250494be8d002ebb427b08f, adding support
for FreeBSD/powerpc64*.
2. Add sanitizer list to lib/libclang_rt/Makefile, taken from the list of
libraries that llvm-devel port builds.
3. powerpc64le supports the same sanitizers that powerpc64, but powerpc64le
also supports xray* sanitizers.
4. lib/libclang_rt/xray/Makefile hardcodes amd64-specific files, so that needs
to be conditionalized.
5. Sanitizers are not enabled for powerpc, because powerpc supports only
builtins and profile.

Reviewed by:	dim
Differential Revision: https://reviews.freebsd.org/D35228
Relnotes:	yes
MFC after:	3 days
2022-05-17 21:46:53 +02:00
Dimitry Andric
3a9a9c0ca4 Merge llvm-project release/14.x llvmorg-14.0.3-0-g1f9140064dfb
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.3-0-g1f9140064dfb.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:46:42 +02:00
Dimitry Andric
53683b95ef Apply libc++ fix for <ranges> not compiling at all
Merge commit 44cdca37c01a from llvm git (by Arthur O'Dwyer):

  [libc++] Define `namespace views` in its own detail header.

  Discovered in the comments on D118748: we would like this namespace
  to exist anytime Ranges exists, regardless of whether concepts syntax
  is supported. Also, we'd like to fully granularize the <ranges> header,
  which means not putting any loose declarations at the top level.

  Differential Revision: https://reviews.llvm.org/D118809
2022-05-14 13:46:39 +02:00
Dimitry Andric
dbc822f3bc Merge llvm-project release/14.x llvmorg-14.0.0-2-g3f43d803382d
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-2-g3f43d803382d.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:46:31 +02:00
Dimitry Andric
fb03ea46eb Merge llvm-project release/14.x llvmorg-14.0.0-rc4-2-gadd3ab7f4c8a
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc4-2-gadd3ab7f4c8a.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:46:23 +02:00
Dimitry Andric
a1f13cbcbb Apply libc++ fix for firefox visibility push/pop issue
Merge commit 7ab1ab0db401 from llvm git (by Dimitry Andric):

  [libc++] Make __dir_stream visibility declaration consistent

  The class `__dir_stream` is currently declared in two places: as a
  top-level forward declaration in `directory_iterator.h`, and as a friend
  declaration in class `directory_entry`, in `directory_entry.h`.

  The former has a `_LIBCPP_HIDDEN` attribute, but the latter does not,
  causing the Firefox build to complain about the visibility not matching
  the previous declaration. This is because Firefox plays games with
  pushing and popping visibility.

  Work around this by making both `__dir_stream` declarations consistently
  use `_LIBCPP_HIDDEN`.

  Reviewed By: ldionne, philnik, #libc

  Differential Revision: https://reviews.llvm.org/D121639
2022-05-14 13:46:21 +02:00
Dimitry Andric
d781ede639 Merge llvm-project release/14.x llvmorg-14.0.0-rc2-12-g09546e1b5103
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc2-12-g09546e1b5103.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:46:11 +02:00
Dimitry Andric
d56accc7c3 Merge llvm-project release/14.x llvmorg-14.0.0-rc1-74-g4dc3cb8e3255
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14.0.0-rc1-74-g4dc3cb8e3255.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:45:57 +02:00
Dimitry Andric
8885dff6ce Apply fix for asm constraint error in www/php80-opcache
Merge commit 027c16bef4b7 from llvm git (by Nick Desaulniers):

  [X86ISelLowering] permit BlockAddressSDNode "i" constraints for PIC

  When building 32b x86 code as PIC, the existing handling of "i"
  constraints is conservative since generally we have to go through the
  GOT to find references to functions.

  But generally, BlockAddresses from C code refer to the Function in the
  current TU.  Permit BlockAddresses to be used with the "i" constraint
  for those cases.

  I regressed this in
  commit 4edb9983cb8c ("[SelectionDAG] treat X constrained labels as i for asm")

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

  Reviewed By: efriedma, MaskRay

  Differential Revision: https://reviews.llvm.org/D119905
2022-05-14 13:45:37 +02:00
Dimitry Andric
1838bd0f48 Merge llvm-project release/14.x llvmorg-14-init-18315-g190be5457c90
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-18315-g190be5457c90.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:45:25 +02:00
Dimitry Andric
1fd87a682a Merge llvm-project main llvmorg-14-init-18294-gdb01b123d012
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-18294-gdb01b123d012, the last commit before
the upstream release/14.x branch was created.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:44:47 +02:00
Dimitry Andric
04eeddc0aa Merge llvm-project main llvmorg-14-init-17616-g024a1fab5c35
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-17616-g024a1fab5c35.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:44:34 +02:00
Dimitry Andric
0eae32dcef Merge llvm-project main llvmorg-14-init-13186-g0c553cc1af2e
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-13186-g0c553cc1af2e.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:44:01 +02:00
Dimitry Andric
4824e7fd18 Merge llvm-project main llvmorg-14-init-11187-g222442ec2d71
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-11187-g222442ec2d71.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:43:49 +02:00
Dimitry Andric
5e801ac66d Merge llvm-project main llvmorg-14-init-10223-g401b76fdf2b3
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10223-g401b76fdf2b3.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:43:32 +02:00
Dimitry Andric
349cc55c97 Merge llvm-project main llvmorg-14-init-10186-gff7f2cfa959b
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-14-init-10186-gff7f2cfa959b.

PR:		261742
MFC after:	2 weeks
2022-05-14 13:43:05 +02:00
Baptiste Daroussin
0a736f0a6a ASAN: reduce verbosity
When running binaries compiled with libasan in PIE and with ALSR on,
the previous code always print the WARNING message, the new code only
printed it if the run is made with the right verbosity

Before this change, many unit test will always fail because of the extra
message which is printed

Reviewed by:	emaste
Differential Revision:	https://reviews.freebsd.org/D35055
MFC after:	2 weeks
2022-04-25 15:41:32 +02:00
Piotr Kubaj
57b6ac48a9 powerpc: implement __clear_cache
Merge LLVM commit 81f5c6270cdfcdf80e6296df216b696a7a37c8b5.

This fixes runtime of most notably pcre libraries (currently patched in ports),
and probably also other ports since currently __clear_cache() just calls
SIGABRT on powerpc.

MFC after:	3 days
Reviewed by:	dim
Differential Revision: https://reviews.freebsd.org/D34736
2022-04-02 12:47:19 +02:00
Mateusz Guzik
30ed48b0a5 clang: Skip attempts to access /proc/self/fd
In contrast to Linux it does not provide entries which can be readlinked
-- these are just regular files, not giving the expected outcome. That's
on top of procfs not being mounted by default to begin with.

Reviewed by:	dim
Differential Revision:		https://reviews.freebsd.org/D34684
2022-03-27 18:01:38 +00:00
Piotr Kubaj
9b597132ae Merge LLVM commit c03fdd340356 to fix lang/rust on powerpc
Summary:
Without it building rust fails with:
ld: error: CallSiteSplitting.cpp:(function llvm::SmallVectorImpl<std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<std::__1::pair<llvm::ICmpInst*, unsigned int>, 2u> > >::operator=(llvm::SmallVectorImpl<std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<std::__1::pair<llvm::ICmpInst*, unsigned int>, 2u> > >&&): .text._ZN4llvm15SmallVectorImplINSt3__14pairIPNS_10BasicBlockENS_11SmallVectorINS2_IPNS_8ICmpInstEjEELj2EEEEEEaSEOSB_+0xB0): relocation R_PPC_PLTREL24 out of range: -33582208 is not in [-33554432, 33554431]

This will need to be merged to releng/13.1.

Reviewed by:	dim
Differential Revision: https://reviews.freebsd.org/D34652
MFC after:	3 days
2022-03-24 09:06:12 +01:00
Dimitry Andric
8e72f458c6 Fix llvm build after 1b3bef43e3, due to API change
After merging llvm commit b9ca73e1a8fd for PR 262608, it would fail to
compile with:

/usr/src/contrib/llvm-project/llvm/lib/IR/Operator.cpp:197:22: error: no member named 'isZero' in 'llvm::APInt'
   if (!IndexedSize.isZero()) {
        ~~~~~~~~~~~ ^

Upstream refactored their APInt class, and isZero() was one of the newer
methods which did not yet exist in llvm 13.0.0. Fix this by using the
older but equivalent isNullValue() method instead.

Fixes:		1b3bef43e3
MFC after:	3 days
2022-03-20 00:12:58 +01:00
Dimitry Andric
1b3bef43e3 Apply llvm fix for assertion compiling certain versions of Wine
Merge commit b9ca73e1a8fd from llvm git (by Stephen Tozer):

  [DebugInfo] Correctly handle arrays with 0-width elements in GEP salvaging

  Fixes an issue where GEP salvaging did not properly account for GEP
  instructions which stepped over array elements of width 0 (effectively a
  no-op). This unnecessarily produced long expressions by appending
  `... + (x * 0)` and potentially extended the number of SSA values used
  in the dbg.value. This also erroneously triggered an assert in the
  salvage function that the element width would be strictly positive.
  These issues are resolved by simply ignoring these useless operands.

  Reviewed By: aprantl

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

PR:		262608
Reported by:	Damjan Jovanovic <damjan.jov@gmail.com>
MFC after:	3 days
2022-03-19 20:59:04 +01:00