[lldb][Fortran] Added support for base types to DWARFASTParserFortran, tests for DWARFASTParserFortran and a method to get the parser from TypeSystemFortran
[DAG] Don't constant fold opaque constants in visitMULO (#224494)
Opaque constants (created for constants hoisted by ConstantHoisting) are
deliberately not folded by FoldConstantArithmetic for binary operations,
so that the hoisted constant is not rematerialized in each user. The MULO
fold in DAGCombiner did not check for this.
The second test reveals a second opaque constant problem - apparently
our constant RHS canonicalization isn't properly handling opaque
constants. (This change is about three split attempts off of something that
was supposed to be fairly trivial. I decided to stop here.)
Assisted-by: Claude Fable 5.1
Reapply [Support] ToolSession for in-process tool invocation (#224515)
This PR Relands #221996, which was approved and merged but reverted in
#224368 after failures in the Fuchsia builders.
This PR contains two commits:
1. The original approved commit, reapplied without changes.
2. A small follow-up fixing the reported failures.
The problem was that a direct Clang invocation was incorrectly marked as
needing a prepended tool name. When Clang launched cc1 out of process,
we produced:
clang clang -cc1 ...
instead of:
clang -cc1 ...
[11 lines not shown]
[clang-tidy] Skip `decltype(auto)` variables in misc-const-correctness (#224465)
Since #157319 the check analyzes `auto` variables, which also pulled in
`decltype(auto)`. Its fix-it inserts `const`, but `decltype(auto)`
cannot be combined with other type specifiers, so the fix does not
compile:
```cpp
decltype(auto) x = get_ref();
decltype(auto) const x = get_ref(); // error
```
Exclude such variables from the analysis, as no `const` can be added.
Fixes #223940
handbook/multimedia: Add Discord and Jitsi
Jitsi works perfectly on 15.1, Discord has never worked... yet.
Reviewed by: carlavilla
Differential Revision: https://reviews.freebsd.org/D59778
rump/atomic_cas_*: Use __HAVE_ATOMIC64_OPS, not _LP64.
Should fix rump build on hppa since a new use of atomic_inc_64 under
__HAVE_ATOMIC64_OPS sprouted a few days ago:
/home/builds/ab/HEAD/hppa/20260917233410Z-tools/lib/gcc/hppa--netbsd/14.3.0/../../../../hppa--netbsd/bin/ld: /home/builds/ab/HEAD/hppa/20260917233410Z-dest/usr/lib/librumpnet_local.so: undefined reference to `rumpns_atomic_inc_64_nv'
Followup for:
PR kern/60729: incosistent st_ino from the first stat(2) on a socket
[Loads] Fix incorrect replacement of pointers with different provenance (#224281)
isPointerAlwaysReplaceable() uses getUnderlyingObject() to check whether
the two pointers have the same provenance, because in that case the
replacement is always legal. However, getUnderlyingObject() does not
actually guarantee that the provenance is the same: In particular, it
can look through some intrinsics like strip.invariant.group and
launder.invariant.group, which do change the provenance of the pointer.
And replacing the result of those intrinsics with their argument is
indeed incorrect.
Fix this by adding a MustPreserveProvenance argument to the relevant
APIs, and enable it in isPointerAlwaysReplaceable().
Noticed while working on
https://github.com/llvm/llvm-project/pull/224222.
[libc++] Locate libstdc++ by querying GCC in the libstdc++ test configuration (#224335)
Instead of hardcoding various paths to locate libstdc++ artifacts, just
provide the compiler and derive all paths from that. This makes it
simpler to run against a pre-installed libstdc++.
[libc++] Allow specifying a configuration in test-at-commit (#224381)
test-at-commit always generated its own Lit configuration pointing at
the libc++ installation given with --libcxx-installation, which meant it
could only ever test libc++. This patch generalizes this to allow
support passing a custom Lit config, which allows using the script for a
wider array of use cases.
sched: rename sched_schedcpu() to sched_sysinit()
sched_schedcpu() is called only during SYSINIT to start kthread that
calls schedcpu() every second in 4BSD, but its name implies it's doing
what 4BSD's schedcpu() does. Rename this function to sched_sysinit() to
mark that schedulers can use it for its own SYSINIT routine. Note that
their SYSINIT routine does not necessarily need to be similar to 4BSD's
decay in schedcpu().
The scheduler.9 man page is planned to be rewritten from scratch, so no
change to it for now.
Reviewed by: olce
Approved by: olce (mentor)
MFC after: 2 weeks
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59437
sched_4bsd: fix vague comment
The comment "was incremented in schedcpu()" doesn't give enough
background for decrementing ts_slptime by 1 (thus ignoring decay_cpu()
for 1 ts_slptime). More accurately, ts_slptime is decremented by 1
because decay_cpu() has already executed once in schedcpu() when
ts_slptime was 1.
Reviewed by: olce
Approved by: olce (mentor)
MFC after: 2 weeks
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59406
sched_ule: fix comment on ts_slice
In ULE ts_slice stores the number of ticks of slice passed not
remaining.
Reviewed by: olce
Approved by: olce (mentor)
MFC after: 2 weeks
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59407
sched_ule: fix invalid tdq_slice() and sched_slice_min
sched_slice_min should always to be greater than zero. When modifying
sched_slice through sysctl, if the new value is less than
SCHED_SLICE_MIN_DIVISOR, sched_slice_min is computed to zero. Add
imax(1, ...) to prevent this.
tdq_slice() should not return a value less than sched_slice_min since
that will cause integer underflow of ts2->ts_slice in
sched_ule_fork_thread. SCHED_SLICE_MIN_DIVISOR is currently set to 6 so
when load is 5 and sched_slice is 4, the two if conditions in
tdq_slice() will pass and the function will return zero. Thus use imax()
so tdq_slice returns sched_slice_min at minimum.
Reviewed by: olce
Approved by: olce (mentor)
MFC after: 2 weeks
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D59408