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
[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
[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
[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
[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
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.
[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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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=instructionsFixes#53465.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D118744
PR: 264318
Reported by: mandree
MFC after: 3 days
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