[Clang] Fixed an assertion caused by Microsoft integer literals exceeding the maximum value (#212743)
Rewrites the truncation logic for Microsoft integer literals.
Fix #212504
---------
Co-authored-by: A. Jiang <de34 at live.cn>
[ProfileData] Use SortedVectorMap for BodySampleMap, TypeCountMap, and CallsiteTypeMap (#216530)
This patch switches several maps in the sample profile reader/writer
from std::map to SortedVectorMap.
The memory efficiency of SortedVectorMap improves multiple performance
metrics:
Profile merging:
Metric Baseline SortedVectorMap Change
-------------------------------------------------------
Wall Clock 200.22s 157.73s -21.2%
User Time 108.93s 92.79s -14.8%
System Time 70.34s 45.83s -34.8%
Total CPU Time 179.27s 138.62s -22.7%
Peak RSS 58.42 GiB 48.11 GiB -17.6%
Minor Page Faults 28,705,225 17,904,042 -37.6%
Major Page Faults 7 0 -100.0%
[4 lines not shown]
misc/py-onnxruntime: Fix wheel missing the compiled pybind extension
setup.py's per-platform "libs" list decides which capi/ files get bundled
into the wheel as package data. It has dedicated branches for Linux
(manylinux and non-manylinux), Darwin, and Windows, but none for FreeBSD --
which silently fell through to the Windows-oriented default, whose *.dll/
*.pyd glob patterns never match anything here. The wheel built without
error, but ended up missing onnxruntime_pybind11_state.so entirely, along
with libonnxruntime_providers_shared.so and the versioned libonnxruntime.so;
the port previously worked around this with a manual post-install step that
copied the pybind extension in from the raw build tree afterward.
Add a FreeBSD branch to setup.py's libs list, mirroring the already-working
Darwin one (plain package-data entries, no ext_modules), so the wheel now
includes the same compiled artifacts on FreeBSD as it does on every other
supported platform. The now-redundant post-install workaround is removed.
Separately, tools/ci_build/build.py's own bdist_wheel invocation never
exposed a way to control the wheel's output directory, leaving it at
[8 lines not shown]
lang/gcc17-devel: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc17-devel
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc17-devel/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc17-devel/work/gcc-17-20260727/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[14 lines not shown]
lang/gcc16-devel: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc16-devel
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20260725/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[14 lines not shown]
lang/gcc16: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc16
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc16/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc16/work/gcc-16.1.0/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[14 lines not shown]
lang/gcc15-devel: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc15-devel
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc15-devel/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc15-devel/work/gcc-15-20260724/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[14 lines not shown]
lang/gcc17-devel: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc17-devel
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc17-devel/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc17-devel/work/gcc-17-20260727/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[12 lines not shown]
lang/gcc16-devel: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc16-devel
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc16-devel/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc16-devel/work/gcc-16-20260725/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[12 lines not shown]
lang/gcc15-devel: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc15-devel
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc15-devel/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc15-devel/work/gcc-15-20260724/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[12 lines not shown]
lang/gcc16: fix build after base d08296c7ab0d
After base d08296c7ab0d7bb259bf7b8cdf9ffb819c1929ab ("libc: Implement
qualifier-preserving standard library functions"), lang/gcc16
fails to build with an error like:
In file included from /wrkdirs/usr/ports/lang/gcc16/work/.build/gcc/include-fixed/stdio.h:52,
from cp-demangle.c:109:
/wrkdirs/usr/ports/lang/gcc16/work/gcc-16.1.0/libstdc++-v3/../include/libiberty.h:225:14: error: expected identifier or '(' before '_Generic'
225 | extern void *memrchr(const void *, int, size_t);
| ^~~~~~~
This is because memrchr is now a macro, similar to the other functions
in <string.h>, and libiberty.h attempts to incorrectly redeclare it.
In turn, cp-demangle.c includes libiberty.h, but does not include the
config.h generated for libiberty.h, instead using the config.h generated
for libstdc++.
[12 lines not shown]
archivers/py-pybcj: Update 1.0.7 => 1.0.8
Changelog:
https://github.com/miurahr/pybcj/blob/v1.0.8/Changelog.rst
- Specify a more precise library name in the STRIP_CMD.
PR: 297701
Sponsored by: UNIS Labs
Co-authored-by: Vladimir Druzenko <vvd at FreeBSD.org>
[DomTree] Make addChild/removeChild private, update NewGVN caller (#218164)
NewGVN's value numbering loop converges more quickly when blocks are
processed in a reverse post order. The code additionally ensures a
property the pass does not need (commit 6658cc9ead67 in 2016): in a
preorder of the dominator tree the instructions dominated by a block are
contiguous.
Use the default RPO and drop addChild/removeChild callers, so that the
two members can be made private. `opt -passes=newgvn` slightly
decreases.
[mlir][xegpu] Lower dynamic high-D nd load/store via base-pointer fold (#215711)
Reworks lowering of >2D (batched)
`xegpu.create_nd_tdesc`/`load_nd`/`store_nd`/ `prefetch_nd` (batched
GEMM, rank-4 flash-attention) to keep the full high-D memref as the
descriptor source and carry the leading (batch) offsets as a row offset
into a flattened 2D plane, instead of slicing a per-batch
`memref.subview` during blocking.
For example, the wg-level IR read a 4d vector out of a dynamic shaped
memref.
```mlir
%0 = vector.transfer_read %source[%i, %j, %k, %l], %c0
{in_bounds = [true, true, true, true]} : memref<?x?x8x16xf32>,
vector<2x4x8x16xf32>
```
This lowers with no subview — the full memref is the descriptor source
and all four offsets stay on the load:
[35 lines not shown]
