i686, as per the discussion on the freebsd-arch mailing list. Earlier
in r352030, I had already bumped it to i586, to work around missing
atomic 64 bit functions for the i386 architecture.
Relnotes: yes
GCC compilers set __FreeBSD__ statically to a build-time determined
targeted version (which in ports always matches the build host's
version). This means that when building any version (12 or 13, etc.)
of riscv or some other architecture via GCC on a 12.x host,
__FreeBSD__ will always be set to 12. As a result, __FreeBSD__ cannot
be used to reliably detect the target FreeBSD version being built.
Instead, __FreeBSD_version from either <sys/param.h> (in the kernel)
or <osreldate.h> (in userland) should be used.
This changes the gets() test in libc++ to use __FreeBSD_version from
<osreldate.h>.
Reported by: jenkins (riscv64 and amd64-gcc)
Reviewed by: dim, imp
Differential Revision: https://reviews.freebsd.org/D22034
Fix process launch failure on FreeBSD after r365761
Summary:
After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS`
enabled, launching any process on FreeBSD crashes lldb with:
```
Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in
success mode must still be checked prior to being destroyed).
```
This is because `m_operation_thread` and `m_monitor_thread` were
wrapped in `llvm::Expected<>`, but this requires the objects to be
correctly initialized before accessing them.
To fix the crashes, use `llvm::Optional<>` for the members (as
indicated by labath), and use local variables to store the return
values of `LaunchThread` and `StartMonitoringChildProcess`. Then,
only assign to the member variables after checking if the return
values indicated success.
Reviewers: devnexen, emaste, MaskRay, mgorny
Reviewed By: devnexen
Subscribers: jfb, labath, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D68723
PR: 241137
MFC after: 1 month
X-MFC-With: r353358
Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be
checked before access or destruction" when launching executables, while
we sort this out with upstream.
PR: 241137
MFC after: 1 month
X-MFC-With: r353358
checked before access or destruction" when launching executables, while
we sort this out with upstream.
Reported by: jbeich
PR: 241137
MFC after: 1 month
X-MFC-With: r353358
This warning (comparing a pointer against a zero character literal
rather than NULL) has existed since GCC 7.1.0, and was recently added to
Clang trunk.
Almost all of these are harmless, except for fwcontrol's str2node, which
needs to both guard against dereferencing a NULL pointer (though in
practice it appears none of the callers will ever pass one in), as well
as ensure it doesn't parse the empty string as node 0 due to strtol's
awkward interface.
Submitted by: James Clarke <jtrc27@jrtc27.com>
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21914
[X86] Check MI.isConvertibleTo3Addr() before calling
convertToThreeAddress in X86FixupLEAs.
X86FixupLEAs just assumes convertToThreeAddress will return nullptr
for any instruction that isn't convertible.
But the code in convertToThreeAddress for X86 assumes that any
instruction coming in has at least 2 operands and that the second one
is a register. But those properties aren't guaranteed of all
instructions. We should check the instruction property first.
Pull in r365720 from upstream llvm trunk (by Craig Topper):
[X86] Don't convert 8 or 16 bit ADDs to LEAs on Atom in FixupLEAPass.
We use the functions that convert to three address to do the
conversion, but changing an 8 or 16 bit will cause it to create a
virtual register. This can't be done after register allocation where
this pass runs.
I've switched the pass completely to a white list of instructions
that can be converted to LEA instead of a blacklist that was
incorrect. This will avoid surprises if we enhance the three address
conversion function to include additional instructions in the future.
Fixes PR42565.
This should fix assertions/segfaults when compiling certain ports with
CPUTYPE=atom.
PR: 240928
MFC after: 3 days
Calculate binary file offset using address field, bacause software know only offset to known data, not where to load segment.
With that patch, kernel .data section can have any alignment/offset - kernel boor fine.
PR: 235391
Reviewed by: markj
MFC after: 1 month
Differential Revision: D21827
The value of struct_kernel_stat64_sz introduced by review D5021 for
RISC-V was incorrect.
Also add a __riscv_xlen == 64 conditional as the 32-bit ABI is not yet
finalized.
Submitted by: Luís Marques
Differential Revision: https://reviews.freebsd.org/D21684
from the command line. Prior to this the functionality was mostly there
however since the pool type (-t) was not recognized by the -A and -R
command options -- not recognized by getopt(). Additionally the code to
implement the dynamic add and removal of pools didn't work.
When dynamically adding (-A) a pool a type (-t) to specify if the pool
is a tree or hash pool must be specified. When dynamically removing (-R)
a pool, omitting -t will cause a search-and-destroy which will remove
both types of pools matching the name given (-m).
PR: 218433
MFC after: 1 week
conflicts with the command option of the same name (also -R).
Remove the superfluous and confusing non-global non-command -R option.
PR: 218433
MFC after: 1 week
Only a role of "ipf" is currentlysupported as the other documented
(and undocumented) roles are #ifdef'd out.
The plan is to complete ippool(8) as it is even in its current state
a powerful feature/tool.
PR: 218433
MFC after: 1 month
Summary: When powerpc64 switches to LLVM, use this patch to enable
OpenMP as well. OpenMP on PPC is only for 64-bits, so don't make a
32-bit libomp. A change to openmp files is necesssary (under review on
https://reviews.llvm.org/D67190), because it determines ELF format
version based on endianness, which is incorrect.
Reviewed by: alfredo.junior_eldorado.org.br, #manpages
Differential Revision: https://reviews.freebsd.org/D21532
Sync libarchive with vendor.
Relevant vendor changes:
Issue #1237: Fix integer overflow in archive_read_support_filter_lz4.c
PR #1249: Correct some typographical and grammatical errors.
PR #1250: Minor corrections to the formatting of manual pages
MFC after: 1 week
Relevant vendor changes:
Issue #1237: Fix integer overflow in archive_read_support_filter_lz4.c
PR #1249: Correct some typographical and grammatical errors.
PR #1250: Minor corrections to the formatting of manual pages
When an empty pattern is encountered in the pattern list, I had previously
broken bsdgrep to count that as a "match all" and ignore any other patterns
in the list. This commit rectifies that mistake, among others:
- The -v flag semantics were not quite right; lines matched should have been
counted differently based on whether the -v flag was set or not. procline
now definitively returns whether it's matched or not, and interpreting
that result has been kicked up a level.
- Empty patterns with the -x flag was broken similarly to empty patterns
with the -w flag. The former is a whole-line match and should be more
strict, only matching blank lines. No -x and no -w will will match the
empty string at the beginning of each line.
- The exit code with -L was broken, w.r.t. modern grep. Modern grap will
exit(0) if any file that didn't match was output, so our interpretation
was simply backwards. The new interpretation makes sense to me.
Tests updated and added to try and catch some of this.
This misbehavior was found by autoconf while fixing ports found in PR 229925
expecting either a more sane or a more GNU-like sed.
MFC after: 1 week
[x86] fix assert with horizontal math + broadcast of vector (PR43402)
https://bugs.llvm.org/show_bug.cgi?id=43402
This should fix 'Assertion failed: ((HOp.getValueType() == MVT::v2f64 ||
HOp.getValueType() == MVT::v4f64) && HOp.getValueType() == VT &&
"Unexpected type for h-op"), function foldShuffleOfHorizOp, file
contrib/llvm/lib/Target/X86/X86ISelLowering.cpp, line 33661' when
building the devel/llvm90 port with CPUTYPE=haswell.
PR: 240759
[mips] Deduce MIPS specific ELF header flags from `emulation`
In case of linking binary blobs which do not have any ELF headers, we
can deduce MIPS ABI ELF header flags from an `emulation` option.
Patch by Kyle Evans.
Requested by: kevans :)
When evaluating a __builtin_constant_p conditional, always enter
constant-folding mode regardless of the original evaluation mode.
In order for this to be correct, we need to track whether we're
checking for a potential constant expression or checking for
undefined behavior separately from the evaluation mode enum, since we
don't want to clobber those states when entering constant-folding
mode.
This should fix "ld: error: undefined symbol: ix86_isa_flags" (and many
other symbol names) during the initial stages of the lang/gcc* ports.
The issue was that without optimization, the __builtin_constant_p()
expressions generated in gencondmd.c would emit references to global
variables that were undefined, such as ix86_isa_flags.
PR: 240629
Unfortunately though the original tarball supports this in ./configure
(for Linux), to fully support disabling of mlockall() by default requires
a little extra help otherwise the following is logged in syslog:
Cannot set RLIMIT_MEMLOCK: Operation not permitted
MFC after: 2 weeks
X-MFC with: r352304
Add -m(no)-spe to clang
Summary:
r337347 added support for the Signal Processing Engine (SPE) to LLVM.
This follows that up with the clang side.
This adds -mspe and -mno-spe, to match GCC.
Subscribers: nemanjai, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D49754
Instead, pull in r371324 from upstream libc++ trunk (by me):
Remove ::gets for FreeBSD 13 and later
Summary:
In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed
gets() from FreeBSD 13's libc, and our copies of libc++ and
libstdc++. In that change, the declarations were simply deleted, but
I would like to propose this conditional test instead.
Reviewers: EricWF, mclow.lists, emaste
Reviewed By: mclow.lists
Subscribers: krytarowski, christof, ldionne, emaste, libcxx-commits
Differential Revision: https://reviews.llvm.org/D67316
This makes these changes more MFCable.
On arm and arm64, where chars are unsigned by default, buildworld dies
with:
--- terminal.o ---
/usr/src/contrib/libedit/terminal.c:569:41: error: comparison of
integers of different signs: 'wint_t' (aka 'int') and 'wchar_t' (aka
'unsigned int') [-Werror,-Wsign-compare]
el->el_cursor.v][where & 0370] !=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/src/contrib/libedit/terminal.c:659:28: error: comparison of
integers of different signs: 'wint_t' (aka 'int') and 'wchar_t' (aka
'unsigned int') [-Werror,-Wsign-compare]
[el->el_cursor.h] == MB_FILL_CHAR)
~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
Fix this by making MB_FILL_CHAR a wint_t, so no casting is needed.
Note that in https://reviews.freebsd.org/D21584 this was also proposed
by Yuichiro Naito <naito.yuichiro_gmail.com>.
Reviewed by: bapt
Subscribers: naito.yuichiro_gmail.com, ml_vishwin.info
MFC after: 3 weeks
X-MFC-With: r352275
Differential Revision: https://reviews.freebsd.org/D21657
leading to hundreds of lines of fairly unreadable error messages.
I don't think we particularly care about the specific source file gcc
dies on, and the many layers of macros and sub-types in googletest make
it very hard to diagnose whether this is a bug in googletest, gcc, clang
or libc++.
Re-commit r357452 (take 3): "SimplifyCFG
SinkCommonCodeFromPredecessors: Also sink function calls without used
results (PR41259)"
Third time's the charm.
This was reverted in r363220 due to being suspected of an internal
benchmark regression and a test failure, none of which turned out to
be caused by this.
As reported in https://bugs.llvm.org/show_bug.cgi?id=43269, this causes
UNREACHABLE errors when compiling if_malo_pci.c for arm and aarch64.
