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
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
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
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
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
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
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
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
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
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
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
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
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
Merge commit f457863ae345 from llvm git (by Fangrui Song):
[ELF] Support REL-format R_AARCH64_NONE relocation
-fprofile-use=/-fprofile-sample-use= compiles may produce REL-format
.rel.llvm.call-graph-profile even if the prevailing format is RELA on AArch64.
Add R_AARCH64_NONE to getImplicitAddend to fix this linker error:
```
ld.lld: error: internal linker error: cannot read addend for relocation R_AARCH64_NONE
PLEASE submit a bug report to https://crbug.com and run tools/clang/scripts/process_crashreports.py (only works inside Google) which will upload a report and include the crash backtrace.
```
Merge commit 53fc5d9b9a01 from llvm git (by Fangrui Song):
[ELF] Support R_PPC_NONE/R_PPC64_NONE in getImplicitAddend
Similar to f457863ae345d2635026501f5383e0e625869639
Merge commit 767e64fc11d7 from llvm git (by Fangrui Song):
[ELF] Support some absolute/PC-relative relocation types for REL format
ctfconvert seems to use REL-format `.rel.SUNW_dof` for 32-bit architectures.
```
Binary file usr/ports/lang/perl5.32/work/perl-5.32.1/dtrace_mini.o matches
[alfredo.junior@dell-a ~/tmp/llvm-bug]$ readelf -r dtrace_mini.o
Relocation section (.rel.SUNW_dof):
r_offset r_info r_type st_value st_name
00000184 0000281a R_PPC_REL32 00000000 $dtrace1772974259.Perl_dtrace_probe_load
```
Support R_PPC_REL32 to fix `ld.lld: error: drti.c:(.SUNW_dof+0x4E4): internal linker error: cannot read addend for relocation R_PPC_REL32`.
While here, add some common relocation types for AArch64, PPC, and PPC64.
We perform minimum tests.
Reviewed By: adalava, arichardson
Differential Revision: https://reviews.llvm.org/D120535
Requested by: alfredo
MFC after: 3 days
Merge commit 28fb22c90fe7 from llvm git (by Dimitry Andric):
[TSan] Handle FreeBSD specific indirection of libpthread functions
Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the
following pthread related functions:
- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)
In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.
ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D119034
MFC after: 3 days
Some sanitizers (at least msan) currently require ASLR to be disabled.
When we detect that ASLR is enabled, re-exec with it disabled rather
than exiting with an error. See LLVM GitHub issue 53256 for more
detail: https://github.com/llvm/llvm-project/issues/53256
No objection: dim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33934
Based on getMainExecutable() in llvm/lib/Support/Unix/Path.inc.
This will need a little more work for an upstream change as it must
support older FreeBSD releases that lack elf_aux_info() / AT_EXEC_PATH.
No objection: dim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33934
Merge commit 6b0f35931a44 from llvm git (by Jennifer Yu):
Fix signal during the call to checkOpenMPLoop.
The root problem is a null pointer is accessed during the call to
checkOpenMPLoop, because loop up bound expr is an error expression
due to error diagnostic was emit early.
To fix this, in setLCDeclAndLB, setUB and setStep instead return false,
return true when LB, UB or Step contains Error, so that the checking is
stopped in checkOpenMPLoop.
Differential Revision: https://reviews.llvm.org/D107385
Note this only fixes the assertion reported in bug 261567; some other
tweaks for port dependencies are probably still required to make it
build to completion.
PR: 261567
MFC after: 3 days
Merge commit c7c84b90879f from llvm git (by Adrian Prantl):
[DwarfDebug] Refuse to emit DW_OP_LLVM_arg values wider than 64 bits
DwarfExpression::addUnsignedConstant(const APInt &Value) only supports
wider-than-64-bit values when it is used to emit a top-level DWARF
expression representing the location of a variable. Before this change,
it was possible to call addUnsignedConstant on >64 bit values within a
subexpression when substituting DW_OP_LLVM_arg values.
This can trigger an assertion failure (e.g. PR52584, PR52333) when it
happens in a fragment (DW_OP_LLVM_fragment) expression, as
addUnsignedConstant on >64 bit values splits the constant into separate
DW_OP_pieces, which modifies DwarfExpression::OffsetInBits.
This change papers over the assertion errors by bailing on overly wide
DW_OP_LLVM_arg values. A more comprehensive fix might be to be to split
wide values into pointer-sized fragments.
[0] https://github.com/llvm/llvm-project/blob/e71fa03/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L799-L805
Patch by Ricky Zhou!
Differential Revision: https://reviews.llvm.org/D115343
MFC after: 3 days
The kern.elf64.aslr.pie_enable and kern.elf32.aslr.pie_enable sysctls
control the default setting for PIE binary address randomization, but
it is possible to enable or disable ASLR on a per-process basis. Use
procctl(2) to query whether ASLR is enabled.
(Note that with ASLR enabled but sysctl kern.elf64.aslr.pie_enable=0
a PIE binary will in effect have randomization disabled, and be
functional with msan. This is not intended as as a user-facing control
though. The user can use proccontrol(1) to disable aslr for the
process.)
Approved by: dim
Obtained from: LLVM 64de0064f315f57044294879d9ff4eacb454d45b
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33933
Since popcnt is only supported by CPUTYPE=nehalem and later, ensure that
this instruction is only emitted when appropriate. Otherwise, programs
using the library can abort with SIGILL.
See also: https://github.com/llvm/llvm-project/issues/52893
PR: 258156
Reported by: Eric Rucker <bhtooefr@bhtooefr.org>
MFC after: 3 days
Merge commit 77e8f4eeeeed from llvm git (by David Green):
[ARM] Define ComplexPatternFuncMutatesDAG
Some of the Arm complex pattern functions call canExtractShiftFromMul,
which can modify the DAG in-place. For this to be valid and handled
successfully we need to define ComplexPatternFuncMutatesDAG.
Differential Revision: https://reviews.llvm.org/D107476
When building parts of llvm targeting armv6 on stable/12, the following
assertion can appear (or if assertions are disabled, clang is likely to
crash):
Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE && "NodeToMatch was removed partway through selection"), function SelectCodeCommon, file /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 3573.
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/obj/usr/src/freebsd12-amd64/tmp/usr/bin/c++ -cc1 -triple armv6kz-unknown-freebsd12.3-gnueabihf -S --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -mrelocation-model static -mconstructor-aliases -target-cpu arm1176jzf-s -target-feature +vfp2 -target-feature +vfp2sp -target-feature -vfp3 -target-feature -vfp3d16 -target-feature -vfp3d16sp -target-feature -vfp3sp -target-feature -fp16 -target-feature -vfp4 -target-feature -vfp4d16 -target-feature -vfp4d16sp -target-feature -vfp4sp -target-feature -fp-armv8 -target-feature -fp-armv8d16 -target-feature -fp-armv8d16sp -target-feature -fp-armv8sp -target-feature -fullfp16 -target-feature +fp64 -target-feature -d32 -target-feature -neon -target-feature -sha2 -target-feature -aes -target-feature -fp16fml -target-feature +strict-align -target-abi aapcs-linux -mfloat-abi hard -fallow-half-arguments-and-returns -ffunction-sections -fdata-sections -O1 -std=c++14 -fdeprecated-macro -fno-rtti -fno-signed-char -faddrsig -fexperimental-new-pass-manager PPCISelLowering-009095.ii
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'PPCISelLowering-009095.cpp'.
4. Running pass 'ARM Instruction Selection' on function '@_ZN4llvm17PPCTargetLoweringC2ERKNS_16PPCTargetMachineERKNS_12PPCSubtargetE'
This crash or assertion is fixed by the upstream commit.
MFC after: 3 days
Merge commit e5a8af7a90c6 from llvm git (by Gulfem Savrun Yeniceri):
[Passes] Fix relative lookup table converter pass
This patch fixes the relative table converter pass for the lookup table
accesses that are resulted in an instruction sequence, where gep is not
immediately followed by a load, such as gep being hoisted outside the loop
or another instruction is inserted in between them. The fix inserts the
call to load.relative.instrinsic in the original place of load instead of gep.
Issue is reported by FreeBSD via https://bugs.freebsd.org/259921.
Differential Revision: https://reviews.llvm.org/D115571
PR: 259921
Reported by: O. Hartmann <freebsd@walstatt-de.de>
MFC after: 3 days
Revert commit e655e74a318e from llvm git (by Peter Collingbourne):
AST: Create __va_list in the std namespace even in C.
This ensures that the mangled type names match between C and C++,
which is significant when using -fsanitize=cfi-icall. Ideally we
wouldn't have created this namespace at all, but it's now part of
the ABI (e.g. in mangled names), so we can't change it.
Differential Revision: https://reviews.llvm.org/D104830
As reported by Jessica in https://reviews.llvm.org/D104830#3129527, this
upstream change is implemented in such a way that it breaks DTrace's
CTF. Since a proper fix has not yet been forthcoming, and we are
unaffected by the (CFI-related) problem upstream was trying to address,
revert the change for now.
Requested by: jrtc27
MFC after: 3 days
Merge commit df08b2fe8b35 from llvm git (by Dimitry Andric):
[AArch64] Avoid crashing on invalid -Wa,-march= values
As reported in https://bugs.freebsd.org/260078, the gnutls Makefiles
pass -Wa,-march=all to compile a number of assembly files. Clang does
not support this -march value, but because of a mistake in handling
the arguments, an unitialized Arg pointer is dereferenced, which can
cause a segfault.
Work around this by adding a check if the local WaMArch variable is
initialized, and if so, using its value in the diagnostic message.
Reviewed By: tschuett
Differential Revision: https://reviews.llvm.org/D114677
PR: 260078
Reported by: bz
MFC after: 3 days
Merge commit e27a6db5298f from llvm git (by Jameson Nash):
Bad SLPVectorization shufflevector replacement, resulting in write to wrong memory location
We see that it might otherwise do:
%10 = getelementptr {}**, <2 x {}***> %9, <2 x i32> <i32 10, i32 4>
%11 = bitcast <2 x {}***> %10 to <2 x i64*>
...
%27 = extractelement <2 x i64*> %11, i32 0
%28 = bitcast i64* %27 to <2 x i64>*
store <2 x i64> %22, <2 x i64>* %28, align 4, !tbaa !2
Which is an out-of-bounds store (the extractelement got offset 10
instead of offset 4 as intended). With the fix, we correctly generate
extractelement for i32 1 and generate correct code.
Differential Revision: https://reviews.llvm.org/D106613
Merge commit 029f1a534489 from llvm git (by Arthur Eubanks):
[LazyCallGraph] Skip blockaddresses
blockaddresses do not participate in the call graph since the only
instructions that use them must all return to someplace within the
current function. And passes cannot retrieve a function address from a
blockaddress.
This was suggested by efriedma in D58260.
Fixes PR50881.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D112178
Merge commit f5755c0849a5 from llvm git (by Jessica Clarke):
[Mips] Add glue between CopyFromReg, CopyToReg and RDHWR nodes for TLS
The MIPS ABI requires the thread pointer be accessed via rdhwr $3, $r29.
This is currently represented by (CopyToReg $3, (RDHWR $29)) followed by
a (CopyFromReg $3). However, there is no glue between these, meaning
scheduling can break those apart. In particular, PR51691 is a report
where PseudoSELECT_I was moved to between the CopyToReg and CopyFromReg,
and since its expansion uses branches, it split the def and use of the
physical register between two basic blocks, resulting in the def being
eliminated and the use having no def. It also seems possible that a
similar situation could arise splitting up the CopyToReg from the RDHWR,
causing the RDHWR to use a destination register other than $3, violating
the ABI requirement.
Thus, add glue between all three nodes to ensure they aren't split up
during instruction selection. No regression test is added since any test
would be implictly relying on specific scheduling behaviour, so whilst
it might be testing that glue is preventing reordering today, changes to
scheduling behaviour could result in the test no longer being able to
catch a regression here, as the reordering might no longer happen for
other unrelated reasons.
Fixes PR51691.
Reviewed By: atanasyan, dim
Differential Revision: https://reviews.llvm.org/D111967
Merge commit c9539f957f57 from llvm git (by Nemanja Ivanovic):
[PowerPC] Define XL-compatible macros only for AIX and Linux
Since XLC only ever shipped on PowerPC AIX and Linux, it is not
reasonable to provide the compatibility macros on any target other
than those two. This patch restricts those macros to AIX/Linux.
Differential revision: https://reviews.llvm.org/D110213
PR: 258209
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.
PR: 258209
MFC after: 2 weeks
Merge commit 2d8c18fbbdd1 from llvm git (by Jessica Clarke):
[X86] Don't add implicit REP prefix to VIA PadLock xstore
Commit 8fa3e8fa1492 added an implicit REP prefix to all VIA PadLock
instructions, but GNU as doesn't add one to xstore, only all the others.
This resulted in a kernel panic regression in FreeBSD upon updating to
LLVM 11 (https://bugs.freebsd.org/259218) which includes the commit in
question. This partially reverts that commit.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D112355
MFC after: 3 days
As reported by Ronald, adding the out-of-line LSE atomics helpers for
aarch64 to compiler-rt was not sufficient to link programs using these,
as they also require a __aarch64_have_lse_atomics global. This is
initialized in compiler-rt's lib/builtins/cpu_model.c, roughly similar
to the x86 CPU model and feature detection in that file.
Since upstream does not yet have a FreeBSD specific implementation for
getting the required information, add a simple one that should work for
now, while I try to get it sorted with the LLVM people.
Reported by: Ronald Klop <ronald-lists@klop.ws>
Fixes: cc55ee8009
PR: 257392
MFC after: 2 weeks
Reverts llvm commit 42eaf4fe0adef3344adfd9fbccd49f325cb549ef, pointed
from bisect as source of regression that causes liblzma to compress/
uncompress incorrectly. It's know to affect powerpc64 BE only.
The patch unbreaks FreeBSD powerpc64 installation media, since
bsdinstall can't uncompress the *.txz produced by FreeBSD CI. It's
probably miscompiling other software bas well.
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=51714
Reviewed by: dim
MFC after: 2 days
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D31804
Amends LLVM commit 2518433f861fcb877d0a7bdd9aec1aec1f77505a that
was pointed as the source of regression on LLVM12.
This affects powerpc64*, making binaries crash with segmentation fault
due to bad code generation around "__stack_chk_guard"
Root cause and/or proper fix is under investigation by:
https://bugs.llvm.org/show_bug.cgi?id=51590
Reviewed by: dim
MFC after: 2 days
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D31698
Merge commit 79f9cfbc21e0 from llvm git (by Yaxun (Sam) Liu):
Do not merge LocalInstantiationScope for template specialization
A lambda in a function template may be recursively instantiated. The recursive
lambda will cause a lambda function instantiated multiple times, one inside another.
The inner LocalInstantiationScope should not be marked as MergeWithParentScope
since it already has references to locals properly substituted, otherwise it causes
assertion due to the check for duplicate locals in merged LocalInstantiationScope.
Reviewed by: Richard Smith
Differential Revision: https://reviews.llvm.org/D98068
Reported by: yuri
PR: 257978
MFC after: 3 days
Merge commit 5033f0793fe6 from llvm git (by Dimitry Andric):
[lldb] Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage
When assertions are turned off, the `llvm::Error` value created at the
start of this function is overwritten using the move-assignment
operator, but the success value is never checked. Whenever a TypeSystem
cannot be found or created, this can lead to lldb core dumping with:
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
Fix this by not creating a `llvm::Error` value in advance, and directly
returning the result of `llvm::make_error` instead, whenever an error is
encountered.
See also: <https://bugs.freebsd.org/253881> and
<https://bugs.freebsd.org/257829>.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D108088
Reported by: dmgk, ota@j.email.ne.jp
PR: 253881, 257829
MFC after: 3 days
Merge commit c6ebc651b6fa from llvm git (by Simon Atanasyan):
[LLD] Support compressed input sections on big-endian targets
This patch enables compressed input sections on big-endian targets by
checking the target endianness and selecting an appropriate `Chdr`
structure.
Fixes PR51369
Differential Revision: https://reviews.llvm.org/D107635
Reported by: emaste
MFC after: 3 days
This is needed in order to build various LLVM binutils (e.g. addr2line)
as well as clang/lld/lldb.
Co-authored-by: Jessica Clarke <jrtc27@FreeBSD.org>
Test Plan: Compiles on ubuntu 18.04 and macOS 11.4
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D31057
Revert commit 22b615a96593 from llvm git (by Daniel Kiss):
[libunwind] Support for leaf function unwinding.
Unwinding leaf function is useful in cases when the backtrace finds a
leaf function for example when it caused a signal.
This patch also add the support for the DW_CFA_undefined because it marks
the end of the frames.
Ryan Prichard provided code for the tests.
Reviewed By: #libunwind, mstorsjo
Differential Revision: https://reviews.llvm.org/D83573
Reland with limit the test to the x86_64-linux target.
Bisection has shown that this particular upstream commit causes programs
using backtrace(3) on aarch64 to segfault. This affects the lang/rust
port, for instance. Until we can upstream to fix this problem, revert
the commit for now.
Reported by: mikael
PR: 256864
In FreeBSD 14 we will stop providing _p libraries (compiled with -pg).
Reviewed by: dim (upstream)
Obtained from: LLVM 699d47472c3f
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30861
Merge commit 789708617d20 from llvm git (Koutheir Attouchi):
Do not generate calls to the 128-bit function __multi3() on 32-bit ARM
Re-applying this patch after bots failures. Should be fine now.
The function __multi3() is undefined on 32-bit ARM, so a call to it should
never be emitted. Instead, plain instructions need to be generated to
perform 128-bit multiplications.
Differential Revision: https://reviews.llvm.org/D103906
Reported by: mmel
MFC after: 3 days
Merge commit 52e9d80d5db2 from llvm git (by Jason Liu):
[libc++] add `inline` for __open's definition in ifstream and ofstream
Summary:
When building with gcc on AIX, it seems that gcc does not like the
`always_inline` without the `inline` keyword.
So adding the inline keywords in for __open in ifstream and ofstream.
That will also make it consistent with __open in basic_filebuf
(it seems we added `inline` there before for gcc build as well).
Differential Revision: https://reviews.llvm.org/D99422
PR: 255570
MFC after: 6 weeks
Merge commit 5c18d1136665 from llvm git (by Qiu Chaofan)
[SPE] Disable strict-fp for SPE by default
As discussed in PR50385, strict-fp on PowerPC SPE has not been
handled well. This patch disables it by default for SPE.
Reviewed By: nemanjai, vit9696, jhibbits
Differential Revision: https://reviews.llvm.org/D103235
PR: 255570
MFC after: 6 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-12-init-17869-g8e464dd76bef, the last commit before the
upstream release/12.x branch was created.
PR: 255570
MFC after: 6 weeks
Merge commit 99eca1bd9c7a from llvm git (by Mark Johnston):
[Driver] Enable kernel address and memory sanitizers on FreeBSD
Test Plan: using kernel ASAN and MSAN implementations in FreeBSD
Reviewed By: emaste, dim, arichardson
Differential Revision: https://reviews.llvm.org/D98286
Merge commit f511dc75e4c1 from llvm git (by Mark Johnston):
[asan] Add an offset for the kernel address sanitizer on FreeBSD
This is based on a port of the sanitizer runtime to the FreeBSD kernel
that has been commited as https://cgit.freebsd.org/src/commit/?id=38da497a4dfcf1979c8c2b0e9f3fa0564035c147
and the following commits.
Reviewed By: emaste, dim
Differential Revision: https://reviews.llvm.org/D98285
Requested by: markj
MFC after: 3 days
Clang commit ccb4124a4172bf2cb2e1cd7c253f0f1654fce294:
Fix -gz=zlib options for linker
gcc translates -gz=zlib to --compress-debug-options=zlib for both
assembler and linker but clang only does this for assembler.
The linker needs --compress-debug-options=zlib option to compress the
debug sections in the generated executable or shared library.
Due to this bug, -gz=zlib has no effect on the generated executable or
shared library.
This patch fixes that.
Clang commit 462cf39a5c180621b56f7602270ce33eb7b68d23:
[Driver] Fix -gz=zlib options for linker also on FreeBSD
ccb4124a4172 fixed translating -gz=zlib to --compress-debug-sections for
linker invocation for several ToolChains, but omitted FreeBSD.
Approved by: dim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29028
Merge commit 740a164de from llvm git (by Richard Smith):
PR46377: Fix dependence calculation for function types and typedef
types.
We previously did not treat a function type as dependent if it had a
parameter pack with a non-dependent type -- such a function type depends
on the arity of the pack so is dependent even though none of the
parameter types is dependent. In order to properly handle this, we now
treat pack expansion types as always being dependent types (depending on
at least the pack arity), and always canonically being pack expansion
types, even in the unusual case when the pattern is not a dependent
type. This does mean that we can have canonical types that are pack
expansions that contain no unexpanded packs, which is unfortunate but
not inaccurate.
We also previously did not treat a typedef type as
instantiation-dependent if its canonical type was not
instantiation-dependent. That's wrong because instantiation-dependence
is a property of the type sugar, not of the type; an
instantiation-dependent type can have a non-instantiation-dependent
canonical type.
Merge commit 9cf98d26e from llvm git (by Richard Smith):
PR46637: Fix handling of placeholder types in trailing-return-types.
Only permit a placeholder type in a trailing-return-type if it would
also have been permitted in the decl-specifier sequence of a
corresponding declaration with no trailing-return-type. The standard
doesn't actually say this, but this is the only thing that makes sense.
Also fix handling of an 'auto' in a trailing-return-type in a parameter
of a generic lambda. We used to crash if we saw such a thing.
Merge commit 234f51a65 from llvm git (by Richard Smith):
Don't crash if we deserialize a pack expansion type whose pattern
contains no packs.
Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.
PR: 252892
Reported by: thierry
MFC after: 3 days
[PowerPC] Do not emit HW loop when TLS var accessed in PHI of loop
exit
If any PHI nodes in loop exit blocks have incoming values from the
loop that are accesses of TLS variables with local dynamic or general
dynamic TLS model, the address will be computed inside the loop.
Since this includes a call to __tls_get_addr, this will in turn cause
the CTR loops verifier to complain. Disable CTR loops in such cases.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=48527
This should fix building ceph 12.2.12 on powerpc64, powerpc, powerpcspe
and powerpc64le.
Requested by: pkubaj
MFC after: 3 days
[RISCV] Set __GCC_HAVE_SYNC_COMPARE_AND_SWAP_x defines
The RISCV target did not set the GCC atomic compare and swap defines,
unlike other targets. This broke builds for things like glib on
RISCV.
Patch by Kristof Provost (kprovost)
Differential Revision: https://reviews.llvm.org/D91784
This should fix building glib20 on RISC-V and unblock a number of
dependent ports.
Requested by: kp
MFC after: 3 days
Implement computeHostNumHardwareThreads() for FreeBSD
This retrieves CPU affinity via FreeBSD's cpuset(2) API, and makes
LLVM respect affinity settings configured by the user via the
cpuset(1) command.
In particular, this allows to reduce the number of threads used on
machines with high core counts, which can interact badly with
parallelized build systems. This is particularly noticable with lld,
which spawns lots of threads even for linking e.g. hello_world!
This fix is related to PR48193, but does not adress the more
fundamental problem, which is that LLVM by default grabs as many CPUs
and/or threads as possible.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D92271
Originally by: mjg
MFC after: 1 week
landed upstream:
For llvm's internal function which retrieves the number of available
"hardware threads", use cpuset_getaffinity(2) on FreeBSD, so it will
honor processor sets configured by the cpuset(1) command.
This should make it possible to avoid e.g. lld creating a huge number of
threads on a machine with many cores, even for linking simple programs.
This will also be submitted upstream.
Submitted by: mjg
-fstack-clash-protection was added in Clang commit e67cbac81211 but was
enabled only on Linux. It should work fine on FreeBSD as well, so
enable it.
To be discussed and upstreamed with a test. The OS test should probably
just be removed.
Reviewed by: dim
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27366
"hardware threads", use cpuset_getaffinity(2) on FreeBSD, so it will
honor processor sets configured by the cpuset(1) command.
This should make it possible to avoid e.g. lld creating a huge number of
threads on a machine with many cores, even for linking simple programs.
This will also be submitted upstream.
Submitted by: mjg
MFC after: 1 week
[ELF] Don't consider SHF_ALLOC ".debug*" sections debug sections
Fixes PR48071
* The Rust compiler produces SHF_ALLOC `.debug_gdb_scripts` (which
normally does not have the flag)
* `.debug_gdb_scripts` sections are removed from `inputSections` due
to --strip-debug/--strip-all
* When processing --gc-sections, pieces of a SHF_MERGE section can be
marked live separately
`=>` segfault when marking liveness of a `.debug_gdb_scripts` which
is not split into pieces (because it is not in `inputSections`)
This patch circumvents the problem by not treating SHF_ALLOC
".debug*" as debug sections (to prevent --strip-debug's stripping)
(which is still useful on its own).
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D91291
This should fix lld segfaulting when linking the rust-based parts of the
devel/py-maturin port.
Reported by: Nick Venenga <nijave@gmail.com>
PR: 250783
MFC after: 3 days
[PowerPC] Skip combining (uint_to_fp x) if x is not simple type
Current powerpc64le backend hits
```
Combining: t7: f64 = uint_to_fp t6
llc: llvm-project/llvm/include/llvm/CodeGen/ValueTypes.h:291:
llvm::MVT llvm::EVT::getSimpleVT() const: Assertion `isSimple() &&
"Expected a SimpleValueType!"' failed.
```
This patch fixes it by skipping combination if `t6` is not simple
type.
Fixed https://bugs.llvm.org/show_bug.cgi?id=47660.
Reviewed By: #powerpc, steven.zhang
Differential Revision: https://reviews.llvm.org/D88388
This should fix the llvm assertion mentioned above when building the
following ports for powerpc64le:
* audio/traverso
* databases/percona57-pam-for-mysql
* databases/percona57-server
* emulators/citra
* emulators/citra-qt5
* games/7kaa
* graphics/dia
* graphics/mandelbulber
* graphics/pcl-pointclouds
* net-p2p/libtorrent-rasterbar
* textproc/htmldoc
Requested by: pkubaj
MFC after: 3 days
When compiling this for mips32 on gcc-6.x, we'd hit issues where we
don't have 64 bit atomics on mips32.
gcc implements this using libatomic, which we don't currently include
in our freebsd-gcc compiler packages.
So for now add this work around so mips32 works. It's also fine for
mips64. We can fix this later once we get libatomic included.
Approved by: dim
Differential Revision: https://reviews.freebsd.org/D26774
[clang][Sema] Fix PR47676: Handle dependent AltiVec C-style cast
Fix premature decision in the presence of type-dependent expression
operands on whether AltiVec vector initializations from single
expressions are "splat" operations.
Verify that the instantiation is able to determine the correct cast
semantics for both the scalar type and the vector type case.
Note that, because the change only affects the single-expression case
(and the target type is an AltiVec-style vector type), the
replacement of a parenthesized list with a parenthesized expression
does not change the semantics of the program in a program-observable
manner.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D88526
This should fix 'Assertion failed: (isScalarType()), function
getScalarTypeKind, file /usr/src/contrib/llvm-project/clang/lib/AST
/Type.cpp, line 2146', when building the graphics/opencv-core port for
powerpc64le.
Requested by: pkubaj
MFC after: 4 weeks
X-MFC-With: r364284
[X86] Place new constant node in topological order in
X86DAGToDAGISel::matchBitExtract
Fixes PR47482
This should fix 'Assertion failed: (Op->getNodeId() != -1 && "Node has
already selected predecessor node"), function DoInstructionSelection,
file
/usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp,
line 1149' when compiling part of the project_painter project, while
targeting the bdver2 (or higher) CPU.
Reported by: jkim
MFC after: 6 weeks
X-MFC-With: r364284
[Sema] Introduce BuiltinAttr, per-declaration builtin-ness
Instead of relying on whether a certain identifier is a builtin,
introduce BuiltinAttr to specify a declaration as having builtin
semantics.
This fixes incompatible redeclarations of builtins, as reverting the
identifier as being builtin due to one incompatible redeclaration
would have broken rest of the builtin calls.
Mostly-compatible redeclarations of builtins also no longer have
builtin semantics. They don't call the builtin nor inherit their
attributes.
A long-standing FIXME regarding builtins inside a namespace enclosed
in extern "C" not being recognized is also addressed.
Due to the more correct handling attributes for builtin functions are
added in more places, resulting in more useful warnings.
Tests are updated to reflect that.
Intrinsics without an inline definition in intrin.h had `inline` and
`static` removed as they had no effect and caused them to no longer
be recognized as builtins otherwise.
A pthread_create() related test is XFAIL-ed, as it relied on it being
recognized as a builtin based on its name.
The builtin declaration syntax is too restrictive and doesn't allow
custom structs, function pointers, etc.
It seems to be the only case and fixing this would require reworking
the current builtin syntax, so this seems acceptable.
Fixes PR45410.
Reviewed By: rsmith, yutsumi
Differential Revision: https://reviews.llvm.org/D77491
This should fix 'Assertion failed: (i < getNumParams() && "Illegal
param #"), function getParamDecl, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/Decl.h, line 2430'
when building the graphics/pgplot port.
Note that there may also have been other ports which triggered this
assertion, if they redeclare standard functions with incompatible
arguments.
Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284
Teach clang that powerpc64le-*-freebsd* is a valid triple.
This is already in upstream clang, but was too late for llvm 11.0.0.
Apply it directly for now, until it can be backported to llvm 11.0.1.
See upstream https://reviews.llvm.org/D73425 for details.
Reviewed by: dim (upstream version), emaste
Approved by: emaste
Differential Revision: https://reviews.freebsd.org/D26400
[X86] SSE4_A should only imply SSE3 not SSSE3 in the frontend.
SSE4_1 and SSE4_2 due imply SSSE3. So I guess I got confused when
switching the code to being table based in D83273.
Fixes PR47464
This should fix builds with -march=amdfam10 emitting SSSE3 instructions
such as pshufb, which lead to programs crashing with SIGILL on such
processors.
Reported by: avg
MFC after: 6 weeks
X-MFC-With: r364284
Add <stdarg.h> include to kmp_os.h, to get the va_list type, required
after cde8f4c164a2. Sort system includes, while here.
The original merged commit works fine by itself on head, but fails to
compile on stable branches because stdarg.h is not implicitly pulled in.
MFC after: immediately, to fix failing builds on stable/{11,12}
Eliminate the sizing template parameter N from CoalescingBitVector
Since the parameter is not used anywhere, and the default size of 16
apparently causes PR47359, remove it. This ensures that IntervalMap
will automatically determine the optimal size, using its NodeSizer
struct.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D87044
This should fix 'Assertion failed: (Elements + Grow <= Nodes * Capacity
&& "Not enough room for elements"), function distribute, file
/usr/src/contrib/llvm-project/llvm/lib/Support/IntervalMap.cpp, line
123.' when building the x11-toolkits/py-wxPython40 port on a i386 host.
Reported by: zeising
MFC after: 6 weeks
X-MFC-With: r364284
There have been several mentions on our mailing lists about missing
atomic functions in our system libraries (e.g. __atomic_load_8 and
friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too.
To address this, add implementations for the functions from compiler-rt
to the system compiler support libraries, e.g. libcompiler_rt.a and and
libgcc_s.so.
This also needs a small fixup in compiler-rt's atomic.c, to ensure that
32-bit mips can build correctly.
Bump __FreeBSD_version to make it easier for port maintainers to detect
when these functions were added.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26159
Move special va_list handling to kmp_os.h
Instead of copying and pasting the same #ifdef expressions in
multiple places, define a type and a pair of macros in kmp_os.h, to
handle whether va_list is pointer-like or not:
* kmp_va_list is the type to use for __kmp_fork_call()
* kmp_va_deref() dereferences a va_list, if necessary
* kmp_va_addr_of() takes the address of a va_list, if necessary
Also add FreeBSD to the list of OSes that has a non pointer-like
va_list. This can now be easily extended to other OSes too.
Reviewed By: AndreyChurbanov
Differential Revision: https://reviews.llvm.org/D86397
This should enable building of LLVM's OpenMP on AArch64. Addition to
share/mk will follow in a subsequent commit.
PR: 248864
MFC after: 2 weeks
Instantiate Error in Target::GetEntryPointAddress() only when
necessary
When Target::GetEntryPointAddress() calls
exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned
entry_addr is valid, it can immediately be returned.
However, just before that, an llvm::Error value has been setup, but
in this case it is not consumed before returning, like is done
further below in the function.
In https://bugs.freebsd.org/248745 we got a bug report for this,
where a very simple test case aborts and dumps core:
* thread #1, name = 'testcase', stop reason = breakpoint 1.1
frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5
1 int main(int argc, char *argv[])
2 {
-> 3 return 0;
4 }
(lldb) p argc
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
Thread 1 received signal SIGABRT, Aborted.
thr_kill () at thr_kill.S:3
3 thr_kill.S: No such file or directory.
(gdb) bt
#0 thr_kill () at thr_kill.S:3
#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890
Fix the incorrect error catch by only instantiating an Error object
if it is necessary.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D86355
This should fix lldb aborting as described in the scenario above.
Reported by: dmgk
PR: 248745
[PowerPC] Fix a typo for InstAlias of mfsprg
D77531 has a type for mfsprg, it should be mtsprg. This patch is to
fix this typo.
This should fix booting powerpc64 kernels, after LLVM 11 was imported.
PR: 248763
resolution for <https://bugs.llvm.org/show_bug.cgi?id=47181>.
The cache implementation depends on dl_iterate_phdr(3) ensuring that its
callbacks are not called simultaneously for multiple threads, but that
is only the case for the dl_iterate_phdr() implementation in rtld.
In a statically linked executable, libc's dl_iterate_phdr() is used,
which does no such locking. If multiple threads then call into the
unwinder at the same time, it is possible to trigger a segfault.
In particular, the statically linked lld which is built during the
cross-tools stage can segfault in this way, because it starts multiple
worker threads that can exit in parallel. Since our pthread_exit(3)
invokes the unwinder, it will therefore call into it in parallel too.
llvm: Default to -mno-relax on RISC-V
Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN
requires unimplemented linker relaxation; recompile with -mno-relax'.
Our default linker (ld.lld) doesn't support relaxation, so default to
no-relax so we don't generate object files the linker can't handle.
Reviewed by: mhorne
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D25210
lldb: use lua as the default script language
In the FreeBSD base system we do not have Python support in lldb, but
will have Lua support. Make Lua the default.
This needs to be made into a configure-time option; that is being
discussed upstream and will appear in a future lldb import. For now
carry this change as a tiny patch to our copy of lldb.
[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time
Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.
On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.
This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim
Differential Revision: https://reviews.freebsd.org/D22549
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM.
In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.
For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)
PR: 233664
Fix llvm-libunwind userspace build on ARM
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or
EHABI or whatever it's called. Export the same ones from LLVM-libunwind's
libgcc_s, on ARM. As part of this, convert libgcc_s from a direct
Version.map to one constructed from component Symbol.map files. This allows
the ARM-specific Symbol.map to be included only on ARM.
Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match
non-ARM definitions and ARM-specific expectations in libcxxrt /
libcompiler_rt.
No functional change intended for non-ARM architectures.
This commit does not actually flip the switch for ARM defaults from libgcc
to llvm-libunwind, but makes it possible (to compile, anyway).
lldb: shorten thread names to make logs easier to follow
lldb prepends the thread name to log entries, and the existing thread
name for the FreeBSD ProcessMonitor thread was longer than the kernel's
supported thread name length, and so was truncated. This made logs hard
to read, as the truncated thread name ran into the log message. Shorten
"lldb.process.freebsd.operation" to just "freebsd.op" so that logs are
more readable.
(Upstreaming to lldb still to be done).
Apply a workaround to be able to build clang 8.0.0 headers with clang
3.4.1, which is still in the stable/10 branch.
It looks like clang 3.4.1 implements static_asserts by instantiating a
temporary static object, and if those are in an anonymous union, it
results in "error: anonymous union can only contain non-static data
members".
To work around this implementation limitation, move the static_asserts
in question out of the anonymous unions.
This should make building the latest stable/11 from stable/10 possible
again.
Reported by: Mike Tancsa <mike@sentex.net>
Put in a temporary workaround for what is likely a gcc 6 bug (it does
not occur with gcc 7 or later). This should prevent the following error
from breaking the head-amd64-gcc CI builds:
In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0:
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
using std::vector<lldb_private::MemoryRegionInfo>::vector;
^~~~~~
/workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
Reported by: CI
Create new EINTEGRITY error with message "Integrity check failed".
An integrity check such as a check-hash or a cross-correlation failed.
The integrity error falls between EINVAL that identifies errors in
parameters to a system call and EIO that identifies errors with the
underlying storage media. EINTEGRITY is typically raised by intermediate
kernel layers such as a filesystem or an in-kernel GEOM subsystem when
they detect inconsistencies. Uses include allowing the mount(8) command
to return a different exit value to automate the running of fsck(8)
during a system boot.
These changes make no use of the new error, they just add it. Later
commits will be made for the use of the new error number and it will
be added to additional manual pages as appropriate.
Reviewed by: gnn, dim, brueffer, imp
Discussed with: kib, cem, emaste, ed, jilles
Differential Revision: https://reviews.freebsd.org/D18765
lldb: remove assertion that target_arch is FreeBSD
The target is not necessarily a FreeBSD binary - for example, it may be
a Linux binary running under the linuxulator. Basic ptrace (live)
debugging already worked in this case, except for the assertion.
Sponsored by: Turing Robotic Industries Inc.
Do not include float interfaces when using libsa.
We don't support float in the boot loaders, so don't include
interfaces for float or double in systems headers. In addition, take
the unusual step of spiking double and float to prevent any more
accidental seepage.
For our lldb customizations, instead of commenting out lines, use #ifdef
LLDB_ENABLE_ALL / #endif preprocess directives instead, so our diffs
against upstream only consist of added lines.
(Note that upstream has largely reshuffled the way optional lldb plugins
are handled, so we need a lot less of these #ifdefs. However, not all of
them can be dropped, unless we re-import several sources that we have
always skipped.)
This revision worked around an endless recursion when compiling clzdi2.c
and ctzdi2.c with gcc, upstream landed a different workaround for this
in https://reviews.llvm.org/rL324593, which is effective enough.
Noticed by: jrtc27
Merge lld trunk r321017 to contrib/llvm/tools/lld.
(Note that in this merge, I foolishly combined upstream changes with
this local change. But only this ifdef part is really needed, as we
always default to ELF link mode.)
Since this is contrib code, create an upstreamable version of my
change. Now on FreeBSD and NetBSD if _STANDALONE is defined, we
include the kernel version with alloances for the quirky differences
between the two.
Sponsored by: Netflix
o Replace __riscv__ with __riscv
o Replace __riscv64 with (__riscv && __riscv_xlen == 64)
This is required to support new GCC 7.1 compiler.
This is compatible with current GCC 6.1 compiler.
RISC-V is extensible ISA and the idea here is to have built-in define
per each extension, so together with __riscv we will have some subset
of these as well (depending on -march string passed to compiler):
__riscv_compressed
__riscv_atomic
__riscv_mul
__riscv_div
__riscv_muldiv
__riscv_fdiv
__riscv_fsqrt
__riscv_float_abi_soft
__riscv_float_abi_single
__riscv_float_abi_double
__riscv_cmodel_medlow
__riscv_cmodel_medany
__riscv_cmodel_pic
__riscv_xlen
Reviewed by: ngie
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11901
libunwind: make __{de,}register_frame compatible with libgcc API
The libgcc __register_frame and __deregister_frame functions take a
pointer to a set of FDE/CIEs, terminated by an entry where length is 0.
In Apple's libunwind implementation the pointer is taken to be to a
single FDE. I suspect this was just an Apple bug, compensated by Apple-
specific code in LLVM.
See lib/ExecutionEngine/RuntimeDyld/RTDyldMemoryManager.cpp and
http://lists.llvm.org/pipermail/llvm-dev/2013-April/061737.html
for more detail.
This change is based on the LLVM RTDyldMemoryManager.cpp. It should
later be changed to be alignment-safe.
Reported by: dim
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8869
Reapply r351610:
Update libunwind custom frame register and deregister functions for
FreeBSD: use the new doubly underscored names for unw_add_dynamic_fde
and unw_remove_dynamic_fde.
NOTE: this should be upstreamed...
Reapply r230021 (by ed):
Add a workaround to prevent endless recursion in compiler-rt.
SPARC and MIPS CPUs don't have special instructions to count
leading/trailing zeroes. The compiler-rt library provides fallback
rountines for these. The 64-bit routines, __clzdi2 and __ctzdi2, are
implemented as simple wrappers around the compiler built-in
__builtin_clz(), assuming these will expand to either 32-bit
CPU instructions or calls to __clzsi2 and __ctzsi2.
Unfortunately, our GCC 4.2 probably thinks that because the operand is
stored in a 64-bit register, it might just be a better idea to invoke
its 64-bit equivalent, simply resulting into endless recursion. Fix this
by defining __builtin_clz and __builtin_ctz to __clzsi2 and __ctzsi2
explicitly.
Reapply r276851:
Update compiler-rt to trunk r224034. This brings a number of new
builtins, and also the various sanitizers. Support for these will be
added in a later commit.
master 2e10b7a39b9, the last commit before the llvmorg-12-init tag, from
which release/11.x was branched.
Note that for now, I rolled back all our local changes to make merging
easier, and I will reapply the still-relevant ones after updating to
11.0.0-rc1.
PR45521: Preserve the value kind when performing a standard
conversion sequence on a glvalue expression.
If the sequence is supposed to perform an lvalue-to-rvalue
conversion, then one will be specified as the first conversion in the
sequence. Otherwise, one should not be invented.
This should fix clang crashing with "can't implicitly cast lvalue to
rvalue with this cast kind", followed by "UNREACHABLE executed at
/usr/src/contrib/llvm-project/clang/lib/Sema/Sema.cpp:538!", when
building recent versions of Ceph, and the CPAN module SYBER/Date-5.2.0.
Reported by: Willem Jan Withagen <wjw@digiware.nl>, eserte12@yahoo.de
PR: 245530, 247812
MFC after: 3 days
llvmorg-10.0.1-rc2-0-g77d76b71d7d.
Also add a few more llvm utilities under WITH_CLANG_EXTRAS:
* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into
.dwp (DWARF package files)
* llvm-size, a size(1) replacement
* llvm-strings, a strings(1) replacement
MFC after: 3 weeks
[BasicAA] Make BasicAA a cfg pass.
Summary:
Part of the changes in D44564 made BasicAA not CFG only due to it
using PhiAnalysisValues which may have values invalidated. Subsequent
patches (rL340613) appear to have addressed this limitation.
BasicAA should not be invalidated by non-CFG-altering passes. A
concrete example is MemCpyOpt which preserves CFG, but we are testing
it invalidates BasicAA.
llvm-dev RFC:
https://groups.google.com/forum/#!topic/llvm-dev/eSPXuWnNfzM
Reviewers: john.brawn, sebpop, hfinkel, brzycki
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74353
This fixes an issue with clang's -fintegrated-cc1 feature, which could
make it output slightly different assembly code, depending on the way it
was invoked.
In r361755 we attempted to work around it by disabling the integrated
cc1 stage, but it did not solve the root cause for all situations.
Extensive testing and bisecting showed that the above change finally
makes the output deterministic, even if -fintegrated-cc1 is on.
Reported by: Fabian Keil <fk@fabiankeil.de>
PR: 246630
MFC after: 3 days
Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN
requires unimplemented linker relaxation; recompile with -mno-relax'.
Our default linker (ld.lld) doesn't support relaxation, so default to
no-relax so we don't generate object files the linker can't handle.
Reviewed by: mhorne
Sponsored by: Axiado
Differential Revision: https://reviews.freebsd.org/D25210
getMainExecutable: Fix hand-rolled AT_EXECPATH for older FreeBSD
Once we hit AT_NULL, we need to bail out of the loop; not just the
enclosing switch. This fixes basic usage (e.g. `cc --version`) when
AT_EXECPATH isn't present on older branches (e.g. under
emu-user-static, at the moment), where we would previously run off
the end of ::environ.
Patch By: kevans
Reviewed By: arichardson
Differential Revision: https://reviews.llvm.org/D79239
MFC after: 3 days
[PowerPC] Add clang -msvr4-struct-return for 32-bit ELF
Summary:
Change the default ABI to be compatible with GCC. For 32-bit ELF
targets other than Linux, Clang now returns small structs in
registers r3/r4. This affects FreeBSD, NetBSD, OpenBSD. There is no
change for 32-bit Linux, where Clang continues to return all structs
in memory.
Add clang options -maix-struct-return (to return structs in memory)
and -msvr4-struct-return (to return structs in registers) to be
compatible with gcc. These options are only for PPC32; reject them on
PPC64 and other targets. The options are like -fpcc-struct-return and
-freg-struct-return for X86_32, and use similar code.
To actually return a struct in registers, coerce it to an integer of
the same size. LLVM may optimize the code to remove unnecessary
accesses to memory, and will return i32 in r3 or i64 in r3:r4.
Fixes PR#40736
Patch by George Koehler!
Reviewed By: jhibbits, nemanjai
Differential Revision: https://reviews.llvm.org/D73290
Requested by: jhibbits
MFC after: 3 days
unsupported relocation on symbol" when assembling arm 'adr' pseudo
instructions. However, the upstream commit did not take big-endian arm
into account.
Applying the same changes to the big-endian handling is straightforward,
thanks to Andrew Turner and Peter Smith for the hint. This will also be
submitted upstream.
MFC after: immediately, since this fix is meant for stable/11
[ARM] Only produce qadd8b under hasV6Ops
When compiling for a arm5te cpu from clang, the +dsp attribute is
set. This meant we could try and generate qadd8 instructions where we
would end up having no pattern. I've changed the condition here to be
hasV6Ops && hasDSP, which is what other parts of ARMISelLowering seem
to use for similar instructions.
Fixed PR45677.
This fixes "fatal error: error in backend: Cannot select: t37: i32 =
ARMISD::QADD8b t43, t44" when compiling sys/dev/sound/pcm/feeder_mixer.c
for armv5. For some reason we do not encounter this on head, but this
error popped up while building universes for stable/12.
MFC after: 3 days
[PowerPC] Do not attempt to reuse load for 64-bit FP_TO_UINT without
FPCVT
We call the function that attempts to reuse the conversion without
checking whether the target matches the constraints that the callee
expects. This patch adds the check prior to the call.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=43976
Differential revision: https://reviews.llvm.org/D77564
This should fix 'Assertion failed: ((Op.getOpcode() == ISD::FP_TO_SINT
|| Subtarget.hasFPCVT()) && "i64 FP_TO_UINT is supported only with
FPCVT"), function LowerFP_TO_INTForReuse, file
/usr/src/contrib/llvm/lib/Target/PowerPC/PPCISelLowering.cpp, line 7276'
when building the devel/libslang2 port (and a few others) for PowerPC64.
Requested by: pkubaj
MFC after: 6 weeks
X-MFC-With: 358851
Use FinishThunk to finish musttail thunks
FinishThunk, and the invariant of setting and then unsetting
CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't
exist when I added this musttail codepath in ab2090d10765 (2014).
Recently in 28328c3771, I started using this codepath on non-Windows
platforms, and users reported problems during release testing
(PR44987).
The issue was already present for users of EH on i686-windows-msvc,
so I added a test for that case as well.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D76444
This should fix 'Assertion failed: (!empty() && "popping exception stack
when not empty"), function popTerminate, file
/usr/src/contrib/llvm-project/clang/lib/CodeGen/CGCleanup.h, line 583'
when building the net-p2p/libtorrent-rasterbar
PR: 244830
Reported by: jbeich, yuri
MFC after: 6 weeks
X-MFC-With: 358851
Fix bots after a9ad65a2b34f
In the last commit, I neglected to initialize the new subtarget
feature I added which caused failures on a few bots. This should fix
that.
This unbreaks the build after r359981, which reverted upstream commit
a9ad65a2b34f.
Reported by: jhibbits (and jenkins :)
MFC after: 6 weeks
X-MFC-With: 358851
[PowerPC] Change default for unaligned FP access for older subtargets
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40554
Some CPU's trap to the kernel on unaligned floating point access and
there are kernels that do not handle the interrupt. The program then
fails with a SIGBUS according to the PR. This just switches the
default for unaligned access to only allow it on recent server CPUs
that are known to allow this.
Differential revision: https://reviews.llvm.org/D71954
This upstream commit causes a compiler hang when building certain ports
(e.g. security/nss, multimedia/x264) for powerpc64. The hang has been
reported in https://bugs.llvm.org/show_bug.cgi?id=45186, but in the mean
time it is more convenient to revert the commit.
Requested by: jhibbits
MFC after: 6 weeks
X-MFC-With: 358851
Make target features check work with ctor and dtor-
The problem was reported in PR45468, applying target features to an
always_inline constructor/destructor runs afoul of GlobalDecl
construction assert when checking for target-feature compatibility.
The core problem is fixed by using the version of the check that
takes a FunctionDecl rather than the GlobalDecl. However, while
writing the test, I discovered that source locations weren't properly
set for this check on ctors/dtors. This patch also fixes constructors
and CALLED destructors.
Unfortunately, it doesn't seem too possible to get a meaningful
source location for a 'cleanup' destructor, so those are still
'frontend' level errors unfortunately. A fixme was added to the test
to cover that situation.
This should fix 'Assertion failed: (!isa<CXXConstructorDecl>(D) && "Use
other ctor with ctor decls!"), function Init, file
/usr/src/contrib/llvm-project/clang/include/clang/AST/GlobalDecl.h, line
45' when compiling the security/botan2 port.
PR: 245550
MFC after: 6 weeks
X-MFC-With: 358851
In the FreeBSD base system we do not have Python support in lldb, but
will have Lua support. Make Lua the default.
This needs to be made into a configure-time option; that is being
discussed upstream and will appear in a future lldb import. For now
carry this change as a tiny patch to our copy of lldb.
