Commit Graph

248 Commits

Author SHA1 Message Date
Mike Karels
f1d5183124 arm64 lib32: change clang to allow -m32 on arm64
The FreeBSD driver support for clang tested explicitly for 32-bit
Intel, MIPS, or PowerPC targets where /usr/lib32/libcrt1.o was
present to decide whether -m32 should use /usr/lib32.  At jrtc27's
suggestion, simply test for a 32-bit platform rather than adding
arm to the list.  Upstreamed as
3450272fc2
Bump the freebsd version to force a bootstrap build.  This is one
step in adding support for -m32 on arm64.

Reviewed by:	jrtc27, brooks, dim
Differential Revision:	https://reviews.freebsd.org/D40943
2023-07-25 18:58:51 -05:00
Dimitry Andric
b8f1c9dd9b Merge commit 2b0f5df7b4e0 from llvm-project (by Jessica Clarke):
[builtins][Mips] Un-break FreeBSD build of __clear_cache

  Commit 674a17e9bbe8 ("MIPS/compiler_rt: use synci to flush icache on
  r6") completely removed the OS-specific guards under the guise of "For
  pre-r6, we can use cacheflush libc function, which is same on Linux and
  FreeBSD." However, the code in question had guards for Linux and
  OpenBSD, not Linux and FreeBSD, and FreeBSD does not have a cacheflush
  libc function as claimed, so this was neither the statement they
  intended to make nor was it sufficient justification for making the code
  completely unconditional. Whilst the upcoming FreeBSD 14 release has
  dropped support for MIPS, FreeBSD 13 has support for it.

  Fix this by only calling cacheflush on the OSes where it was previously
  called, and not on other OSes where it either definitely isn't available
  (FreeBSD) or is unknown (any other OS than the three mentioned in this
  commit).

This is only needed for MFC'ing, as mips has been removed from
14-CURRENT.

PR:		271047
MFC after:	immediately
2023-07-23 13:01:42 +02:00
Dimitry Andric
8d0cab8800 Merge commit 9ca395b5ade1 from llvm-project (by Haojian Wu):
[clang][AST] Propagate the contains-errors bit to DeclRefExpr from VarDecl's initializer.

  Similar to the https://reviews.llvm.org/D86048 (it only sets the bit for C++
  code), we propagate the contains-errors bit for C-code path.

  Fixes https://github.com/llvm/llvm-project/issues/50236
  Fixes https://github.com/llvm/llvm-project/issues/50243
  Fixes https://github.com/llvm/llvm-project/issues/48636
  Fixes https://github.com/llvm/llvm-project/issues/50320

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

This fixes an assertion ('Assertion failed: ((LHSExpr->containsErrors()
|| RHSExpr->containsErrors()) && "Should only occur in error-recovery
path."), function BuildBinOp') when building parts of dtrace in certain
scenarios.

Reported by:	dstolfa
PR:		271047
MFC after:	1 month
2023-07-19 19:14:23 +02:00
Dimitry Andric
881fc20356 Merge commit 8757ce490130 from llvm-project (by Simon Pilgrim):
[PowerPC] Replace PPCISD::VABSD cases with generic ISD::ABDU(X,Y) node

    A move towards using the generic ISD::ABDU nodes on more backends

    Also support ISD::ABDS for v4i32 types using the existing signbit flip trick

    PowerPC has a select(icmp_ugt(x,y),sub(x,y),sub(y,x)) -> abdu(x,y) combine that I intend to move to DAGCombiner in a future patch.

    The ABS(SUB(X,Y)) -> PPCISD::VABSD(X,Y,1) v4i32 combine wasn't legal (https://alive2.llvm.org/ce/z/jc2hLU) - so I've removed it, having already added the legal sub nsw tests equivalent.

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

This fixes a "Wasn't expecting to be able to lower this!" fatal error
when compiling graphics/opencv for PowerPC.

Requested by:	pkubaj
PR:		271047
MFC after:	1 month
2023-07-16 20:45:29 +02:00
Dimitry Andric
1cd9788408 Merge commit fde5924dcc69 from llvm-project (by Serge Pavlov):
[clang] Reset FP options before template instantiation

  AST nodes that may depend on FP options keep them as a difference
  relative to the options outside the AST node. At the moment of
  instantiation the FP options may be different from the default values,
  defined by command-line option. In such case FP attributes would have
  unexpected values. For example, the code:

      template <class C> void func_01(int last, C) {
        func_01(last, int());
      }
      void func_02() { func_01(0, 1); }
      #pragma STDC FENV_ACCESS ON

  caused compiler crash, because template instantiation takes place at the
  end of translation unit, where pragma STDC FENV_ACCESS is in effect. As
  a result, code in the template instantiation would use constrained
  intrinsics while the function does not have StrictFP attribute.

  To solve this problem, FP attributes in Sema must be set to default
  values, defined by command line options.

  This change resolves https://github.com/llvm/llvm-project/issues/63542.

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

Requested by:	pkubaj
PR:		265755, 265758
MFC after:	1 month
2023-07-13 20:57:22 +02:00
Dimitry Andric
e048f78b21 Merge llvm-project release/16.x llvmorg-16.0.6-0-g7cbf1a259152
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.6-0-g7cbf1a259152 (aka 16.0.6 release).

PR:		271047
MFC after:	1 month
2023-06-22 20:22:59 +02:00
Dimitry Andric
cf24393421 Merge commit 69d42eef4bec from llvm-project (by Dimitry Andric):
[Clang] Show type in enum out of range diagnostic

  When the diagnostic for an out of range enum value is printed, it
  currently does not show the actual enum type in question, for example:

      v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
        static constexpr T kMax = static_cast<T>(kNumValues - 1);
                                  ^

  This can make it cumbersome to find the cause for the problem. Add the
  enum type to the diagnostic message, to make it easier.

  Reviewed By: aaron.ballman

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

PR:		271047
MFC after:	1 month
2023-06-22 20:22:54 +02:00
Dimitry Andric
2efbaac7a0 Merge llvm-project release/16.x llvmorg-16.0.5-0-g185b81e034ba
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.5-0-g185b81e034ba (aka 16.0.5 release).

PR:		271047
MFC after:	1 month
2023-06-22 20:22:50 +02:00
Dimitry Andric
a324c34037 Merge llvm-project release/16.x llvmorg-16.0.4-0-gae42196bc493
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.4-0-gae42196bc493 (aka 16.0.4 release).

PR:		271047
MFC after:	1 month
2023-06-22 20:22:43 +02:00
Dimitry Andric
cbe9438cfe Merge llvm-project release/16.x llvmorg-16.0.3-0-gda3cd333bea5
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.3-0-gda3cd333bea5 (aka 16.0.3 release).

PR:		271047
MFC after:	1 month
2023-06-22 20:22:35 +02:00
Dimitry Andric
c3450ad127 clang: re-downgrade implicit int/function declarations to warning only
This reapplies upstream commit c0141f3c300f by Aaron Ballman:

  Downgrade implicit int and implicit function declaration to warning only

  The changes in Clang 15.0.0 which enabled these diagnostics as a
  warning which defaulted to an error caused disruption for people
  working on distributions such as Gentoo. There was an explicit request
  to downgrade these to be warning-only in Clang 15.0.1 with the
  expectation that Clang 16 will default the diagnostics to an error.

  See
  https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
  for more details on the discussion.

  See https://reviews.llvm.org/D133800 for the public review of these
  changes.

As noted in the upstream discussion, there are many programs that fail
to configure or build correctly, if these warnings are turned into
errors by default.

Note that most affected programs in ports are relatively old, and are
unlikely to be fixed by actually adjusting their declarations, but by
compiling with -std=gnu89, which downgrades the errors back to warning
again. Lots of tedious work for very little gain.
2023-06-22 20:22:33 +02:00
Dimitry Andric
9e7101a856 Merge llvm-project release/16.x llvmorg-16.0.2-0-g18ddebe1a1a9
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.2-0-g18ddebe1a1a9 (aka 16.0.2 release).

PR:		271047
MFC after:	1 month
2023-06-22 20:22:28 +02:00
Dimitry Andric
1ac57eed95 Merge commit db492316399a from llvm-project (by Dimitry Andric):
[clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h

  As of https://reviews.llvm.org/D79708, clang-tblgen generates `arm_neon.h`,
  `arm_sve.h` and `arm_bf16.h`, and all those generated files will contain a
  typedef of `bfloat16_t`. However, `arm_neon.h` and `arm_sve.h` include
  `arm_bf16.h` immediately before their own typedef:

      #include <arm_bf16.h>
      typedef __bf16 bfloat16_t;

  With a recent version of clang (I used 16.0.1) this results in warnings:

      /usr/lib/clang/16/include/arm_neon.h:38:16: error: redefinition of typedef 'bfloat16_t' is a C11 feature [-Werror,-Wtypedef-redefinition]

  Since `arm_bf16.h` is very likely supposed to be the one true place where
  `bfloat16_t` is defined, I propose to delete the duplicate typedefs from the
  generated `arm_neon.h` and `arm_sve.h`.

  Reviewed By: sdesmalen, simonbutcher

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

PR:		271047
MFC after:	1 month
2023-06-22 20:22:26 +02:00
Dimitry Andric
482e0fcdf7 Merge commit 16949c5c48ab from llvm-project (by Dimitry Andric):
[compiler-rt] Include system headers before optionally defining HWCAP macros

  In https://reviews.llvm.org/D141285 the optional definitions of `HWCAP`
  macros were moved to before their usage. However, they were also moved
  to before the inclusion of system headers which can optionally define
  them. If any of those system headers then actually defined any of the
  `HWCAP` macros, it would result in a redefinition error.

  Move the system header includes to just before the optional definitions,
  to avoid this problem.

  Reviewed By: ilinpv

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

PR:		271047
MFC after:	1 month
2023-06-22 20:22:25 +02:00
Dimitry Andric
1ac55f4cb0 Merge llvm-project release/16.x llvmorg-16.0.1-0-gcd89023f7979
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16.0.1-0-gcd89023f7979 (aka 16.0.1 release).

PR:		271047
MFC after:	1 month
2023-06-22 20:22:20 +02:00
Dimitry Andric
bdd1243df5 Merge llvm-project main llvmorg-16-init-18548-gb0daacf58f41
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-16-init-18548-gb0daacf58f41.

PR:		271047
MFC after:	1 month
2023-06-22 20:20:56 +02:00
Dimitry Andric
dbbaf77801 Apply llvm fix for hanging gcc builds on 32-bit arm
Merge commit 962c306a11d0 from llvm-project (by Florian Hahn):

  [LV] Don't consider pointer as uniform if it is also stored.

  Update isVectorizedMemAccessUse to also check if the pointer is stored.
  This prevents LV to incorrectly consider a pointer as uniform if it is
  used as both pointer and stored by the same StoreInst.

  Fixes #61396.

PR:		271992
Reported by:	John F. Carr <jfc@mit.edu>
MFC after:	3 days
2023-06-19 20:33:33 +02:00
Dimitry Andric
8792c03886 Apply clang fixes for crashes compiling ARM/AArch64 CRC intrinsics
Merge commit 069ecd0c6e2c from llvm-project (by Fangrui Song):

  [ARM] Check target feature support for __builtin_arm_crc*

  `__builtin_arm_crc*` requires the target feature crc which is available on armv8
  and above. Calling the fuctions for armv7 leads to a SelectionDAG crash.

  ```
  % clang -c --target=armv7-unknown-linux-gnueabi -c a.c
  fatal error: error in backend: Cannot select: intrinsic %llvm.arm.crc32b
  PLEASE submit a bug report to ...
  ```

  Add `TARGET_BUILTIN` and define required features for these builtins to
  report an error in `CodeGenFunction::checkTargetFeatures`. The problem is quite widespread.
  I will add `TARGET_BUILTIN` for more builtins later.

  Fix https://github.com/llvm/llvm-project/issues/57802

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

Merge commit b2d7a0dcf1ff from llvm-project (by Fangrui Song):

  [AArch64] Check target feature support for __builtin_arm_crc*

  This is the AArch64 counterpart of D134127.
  Daniel Kiss will change more `BUILTIN` to `TARGET_BUILTIN`.

  Fix #57802

Note that programs attempting to use ARM/AArch64 CRC intrinsics, when
they are not supported by the targeted CPU, will still receive a regular
compilation error (instead of a fatal backend error) similar to:

  7zCrc.c:4:10: error: '__builtin_arm_crc32b' needs target feature crc
    return __builtin_arm_crc32b(a, b);
           ^

Reported by:	Alastair Hogge <agh@riseup.net>
PR:		271624
MFC after:	3 days
2023-05-29 16:28:18 +02:00
Dimitry Andric
1f571f8767 Apply libc++ fix for compiling <type_traits> with clang 16
Merge commit 0e7971154ecb from llvm-project (by Christopher Di Bella):

  [libcxx][NFC] utilises compiler builtins for unary transform type-traits

  Depends on D116203

  Reviewed By: #libc, philnik

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

Clang 16 got new builtins that are equivalent to hand-written parts of
<type_traits>. When building world with the devel/llvm16 package
installed and CROSS_TOOLCHAIN=llvm16 set, this would lead to -Werror
warnings about those builtins being overridden.

Reported by:	emaste
MFC after:	3 days
2023-05-27 18:19:37 +02:00
Ed Maste
0f2bb40bc7 lldb: dereference stoppcbs based on target kernel version
As of 9fb6718d1b / __FreeBSD_version 1400089 stoppcbs is a pointer to
the pcbs array.  Dereference stoppcbs on sufficiently new kernels.

Reviewed by:	markj (earlier)
Sponsored by:	The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39939
2023-05-25 21:45:52 -04:00
Dimitry Andric
2df58f1907 Apply libc++ fix for compiling <type_traits> with gcc 13
Merge commit 484e64f7e7b2 from llvm-project (by Roland McGrath):

  [libc++] Use __is_convertible built-in when available

  https://github.com/llvm/llvm-project/issues/62396 reports that
  GCC 13 barfs on parsing <type_traits> because of the declarations
  of `struct __is_convertible`.  In GCC 13, `__is_convertible` is a
  built-in, but `__is_convertible_to` is not.  Clang has both, so
  using either should be fine.

  Reviewed By: #libc, philnik

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

Reported by:	Mark Millard <marklmi@yahoo.com>
MFC after:	3 days
2023-05-05 18:19:40 +02:00
Dimitry Andric
56f2446575 Apply clang fix for assertion building emulators/rpcs3
Merge commit a5e1a93ea10f from llvm-project (by Mariya Podchishchaeva):

  [clang] Fix crash when handling nested immediate invocations

  Before this patch it was expected that if there was several immediate
  invocations they all belong to the same expression evaluation context.
  During parsing of non local variable initializer a new evaluation context is
  pushed, so code like this
  ```
  namespace scope {
  struct channel {
      consteval channel(const char* name) noexcept { }
  };
  consteval const char* make_channel_name(const char* name) { return name;}

  channel rsx_log(make_channel_name("rsx_log"));
  }
  ```
  produced a nested immediate invocation whose subexpressions are attached
  to different expression evaluation contexts. The constructor call
  belongs to TU context and `make_channel_name` call to context of
  variable initializer.

  This patch removes this assumption and adds tracking of previously
  failed immediate invocations, so it is possible when handling an
  immediate invocation th check that its subexpressions from possibly another
  evaluation context contains errors and not produce duplicate
  diagnostics.

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

  Reviewed By: aaron.ballman, shafik

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

PR:		269489
MFC after:	3 days
2023-04-28 16:09:45 +02:00
Mateusz Guzik
04bab189b8 llvm/lld: damage control threading
See the comment inside.

Reviewed by:	dim
Differential Revision:	https://reviews.freebsd.org/D39389
2023-04-03 16:05:42 +00:00
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