[CI] Fix C++ extension JIT cache invalidation by ShigureNyako · Pull Request #79293 · PaddlePaddle/Paddle

ShigureNyako · 2026-06-10T06:04:03Z

PR Category

Execute Infrastructure

PR Types

Bug fixes

Description

修复 Linux-CPU custom op JIT 在共享 /root/.cache/paddle_extensions 下可能命中陈旧缓存的问题，并保留一个 CI 侧的临时/防御性 cache cleanup。

背景来自 #79289 的 Linux-CPU 排查：

最近通过样例 80404721798 与失败样例 80467139736 使用相同 Linux-CPU docker image ccr-2vdh3abv-pub.cnc.bj.baidubce.com/ci/paddle:19d3669ca5ff0b19144a785bb3126d7e，且均安装 apache-tvm-ffi==0.1.11，所以 CPU 失败不指向 tvm-ffi==0.1.12。
失败集中在 test_custom_extend_attrs_jit / test_custom_simple_slice / test_custom_inplace，日志显示 paddle.utils.cpp_extension 调用 ninja -v -f /root/.cache/paddle_extensions/.../build.ninja 时 ninja 进程收到 SIGSEGV。
Linux-CPU workflow 将 /home/data/cfs/.cache/python35-cpu 挂载为容器内 /root/.cache，paddle_extensions 位于该共享 cache 下。

本 PR 做两类修复：

BuildExtension 生成 object path 时，避免对已经位于 build_temp 下的 object 再次拼接 build_temp，修正类似 .../temp.../build/.../temp.../build.ninja 的重复路径。
version.txt 的扩展版本签名加入 source file content hash；source 或 build args 变化时，删除 stale .so 以及 build_temp 下的 .o/.obj，避免共享 cache 中旧 object 被 ninja/distutils 复用。
Linux-CPU workflow 在 Test step 进入 run_linux_cpu_test.sh 前，仅清理 /root/.cache/paddle_extensions；不清理整个 /root/.cache，也不动 pip cache / ccache。

本地验证：

python3 -m py_compile python/paddle/utils/cpp_extension/cpp_extension.py python/paddle/utils/cpp_extension/extension_utils.py test/cpp_extension/test_cpp_extension_ninja.py
git diff --check

另外跑了一个 isolated helper validation（stub 掉最小 Paddle import），覆盖：

relative object path 已在 build_temp 下时不会重复拼接；
source content 变化会改变 version signature；
source content 变化时会清理 stale .so 和 .o；
.so 不存在但 stale .o 存在时也会清理 stale .o。

完整 unittest 在本地源码 checkout 中因未构建 paddle.base.libpaddle 无法导入运行，留给 CI 验证。

是否引起精度变化

否

Co-authored-by: Codex <noreply@openai.com>

ShigureNyako

自查了一遍：

变更范围只包含 Linux-CPU workflow 的 Test step。
只清理 /root/.cache/paddle_extensions，不清理整个 /root/.cache，也不动 pip cache / ccache。
目的只是让 custom op JIT 重新生成 /root/.cache/paddle_extensions/.../build.ninja，对应 #79289 中 ninja 在该 cache 路径下 SIGSEGV 的失败指纹。
本地验证已跑：
- sed -n '155,175p' .github/workflows/_Linux-CPU.yml
- git diff --check
- commit 前 pre-commit hooks 通过。

@SigureMo 这个 PR 是按 #79289 里 CPU 流水线排查建议单独提交的。

SigureMo · 2026-06-10T06:35:28Z

好像过了啊！看看 ninja 目前实现是不是有错误命中 cache 的风险？还是生成错误的 ninja file 的风险？

ShigureNyako · 2026-06-10T07:06:12Z

@SigureMo 我补看了实现和当前 CI，先修正一下证据：#79293 这一轮 Linux-CPU 还没有证明“清理后过了”。job 80493976174 在 Download paddle.tar.gz and merge target branch 步骤 30 min timeout，Build/Test 都没跑到，所以还没有执行到 .github/workflows/_Linux-CPU.yml:165-167 的 rm -rf /root/.cache/paddle_extensions + run_linux_cpu_test.sh。

关于 cpp_extension / ninja：

默认 JIT root 是 ~/.cache/paddle_extensions（python/paddle/utils/cpp_extension/extension_utils.py:1196-1201）；Linux-CPU 又把 /home/data/cfs/.cache/python35-cpu 挂到容器内 /root/.cache（.github/workflows/_Linux-CPU.yml:83-84），所以这个目录是跨 job/PR 共享的。
load() 会按传入的 name 使用 <root>/<name> / <root>/build/<name>/...（cpp_extension.py:1733-1764）。[Typing] Upgrade mypy to 2.1.0 and target Python 3.10 #79289 / [CodeStyle] Clean up Python 3.10 type-hint diagnostics #79291 失败的三项正好都是固定 name：custom_extend_attrs_jit、custom_simple_slice_jit、custom_inplace。
当前实现每次都会重写 <...>/build.ninja 后再执行 ninja -v -f <...>/build.ninja（cpp_extension.py:850-858, 1826-1829）。所以我不倾向于认为是“当前代码稳定生成了错误的 ninja file”；如果是确定性的生成错误，fresh dir 下也应稳定复现。
但“错误命中/污染共享 build state”的风险确实存在：目录 key 不是 PR/job scoped，version.txt 只按 sources/flags 等签名处理 .so（extension_utils.py:330-378），而 build.ninja 是普通 open(..., 'w') 写入，无锁且非原子（cpp_extension.py:1810-1817）。在共享 CFS cache 下，旧 .ninja_deps / .ninja_log / object / .so，或并发 job 写同名目录，都可能污染 Ninja 的增量状态；这比“生成逻辑本身错”更符合看到的是 ninja 进程 SIGSEGV。
[Typing] Upgrade mypy to 2.1.0 and target Python 3.10 #79289 job 80467139736、[CodeStyle] Clean up Python 3.10 type-hint diagnostics #79291 job 80464994163 的失败指纹一致：ninja -v -f /root/.cache/paddle_extensions/build/<name>/.../build.ninja died with <Signals.SIGSEGV: 11>，不是编译器报错。

CI 分类：

Mac-CPU job 80493662859：更像 unrelated flaky/runtime。这个 PR 只改 Linux-CPU workflow；Mac 里相关 custom op JIT 测试已通过，最终失败是 test_binary_cross_entropy_with_logits_op / test_transforms_static 的 segfault 与 rerun success rate <50%。
PR-CI-SOT job 80493975633：artifact/infra。失败在 wget .../Paddle.tar.gz，exit code 4，未进入 build/test。
同类 artifact/infra 还有 Linux-build 80493871571、Linux-CPU 80493976174、Distribute-stable-build 80493976403、Coverage build 80494071433：都在下载 Paddle.tar.gz 阶段 timeout/失败，未覆盖实际代码路径。
还有部分 checks 在跑；我先不盲目 rerun。

当前不新增 commit，也不扩大 #79293 的改动范围。这个 PR 仍先保留为最小验证/规避；需要等一轮 Linux-CPU 真正跑到 Test，才能判断清理 /root/.cache/paddle_extensions 是否足够。若后面要把规避做稳，方向应是 job-local PADDLE_EXTENSION_DIR 或避免共享目录并发，而不是改 generated ninja 语法本身。

Co-authored-by: Codex <noreply@openai.com>

ShigureNyako · 2026-06-10T07:25:37Z

@SigureMo 我继续看了下，确实有两个风险点，已经在最新提交 f81295b6af 里补了代码修复和纯 Python 覆盖测试：

build.ninja 路径生成有重复 build_temp 的问题
- BuildExtension 里 object_filenames_with_cuda() 调用原始 object_filenames(..., output_dir=self.build_temp) 后，又无条件 os.path.join(self.build_temp, obj)。
- 失败日志里的路径也能看到这个特征：
```
/root/.cache/paddle_extensions/build/custom_simple_slice_jit/temp.../build/custom_simple_slice_jit/temp.../paddle/build/test/custom_op/build.ninja
```
- 最新提交改成：如果 object 已经在 build_temp 下，就不再重复拼接。
有 stale cache 命中的风险
- 旧 version.txt 的签名只覆盖 source path / compile args / link args 等，不包含 source file content hash。
- 在 CI 的共享 /root/.cache/paddle_extensions 下，如果旧 .so/.o 比新 checkout/extract 出来的 source 更新，distutils/ninja 可能跳过重新编译，复用旧产物。
- 最新提交把 source content hash 加入 version signature；signature 变化时会删除 stale .so，也会清理当前 build_temp 下的 .o/.obj，避免只重新 link 到旧 object。

另外保留 workflow 里只清理 /root/.cache/paddle_extensions 的防御性处理，不动整个 /root/.cache / pip cache / ccache。

本地验证：

python3 -m py_compile python/paddle/utils/cpp_extension/cpp_extension.py python/paddle/utils/cpp_extension/extension_utils.py test/cpp_extension/test_cpp_extension_ninja.py
git diff --check

还跑了一个 isolated helper validation，覆盖了相对路径不重复拼接、source hash 变化、stale .so/.o 清理、以及 .so 不存在但 stale .o 存在时的清理。完整 unittest 本地因为源码 checkout 没有构建 paddle.base.libpaddle 跑不起来，交给 CI 验证。

补充：当前 #79293 旧一轮多项失败（包括 Linux-CPU）没有跑到测试阶段，是在 Downloading Paddle.tar.gz 阶段超时/退出，属于 artifact 下载 infra 问题；新提交已经触发新一轮 CI。

SigureMo · 2026-06-10T07:42:40Z

关键在于，之前为啥一直没问题，是因为 ninja 支持后暴露的问题吗？

ShigureNyako · 2026-06-10T08:00:29Z

@SigureMo 我看了一下 history，结论是：是的，更像是 cpp_extension 的 ninja 支持把原本不充分的 JIT cache invalidation 暴露出来；不是最近 tvm-ffi 这类依赖变化，也不像是某次确定性生成了错误 build.ninja。

具体证据：

cpp_extension 的 use_ninja=True / _run_ninja_build 是 7b7e53f（【Hackathon 10th Spring No.46】[CppExtension] add option to use ninja to compile cpp_extensions -part #78520，2026-05-11）引入的。在这之前 custom op JIT 不会走 ninja -f .../build.ninja，也没有 .ninja_deps / .ninja_log 这类 ninja 增量状态。
Linux-CPU 把 /home/data/cfs/.cache/python35-cpu 挂到 /root/.cache，而默认 JIT root 是 /root/.cache/paddle_extensions；这些测试的 extension name 又是固定的，所以跨 PR / 跨 job 会复用同一批目录。
失败日志里的路径形态有明显异常：/root/.cache/paddle_extensions/build/<name>/temp.../build/<name>/temp.../paddle/build/test/custom_op/build.ninja，说明 object path 曾经被重复拼过 build_temp。这个在 fresh build 下不一定立刻失败，但在共享 cache + ninja 增量状态下容易把错误/陈旧 state 放大成错误命中。
旧的 version.txt 签名只覆盖 sources 路径和编译/链接参数，不覆盖 source content；source 路径在 CI 里稳定是 /paddle/build/test/custom_op/*.cc，所以同名 custom op 的旧 .so/.o 在共享 cache 中有复用风险。

所以“之前一直没问题”的原因更可能是触发条件没凑齐：ninja 支持引入后风险已经存在，但需要共享 CFS cache 里出现同名 extension 的 stale/poisoned object 或 ninja state；cache 干净或状态刚好一致时就会通过。这次连续在 #79289/#79291 看到同三项 custom op JIT 的 ninja SIGSEGV，说明 cache state 已经被污染了。

我已经在 f81295b 里把 PR 从单纯 CI cleanup 收窄成代码侧修复：

避免 object path 对已经在 build_temp 下的路径再次拼接 build_temp；
把 source content hash 加入 version.txt 签名；
source / build args 变化时清理 stale .so 和 build_temp 下的 .o/.obj；
Linux-CPU 侧的 /root/.cache/paddle_extensions cleanup 先保留为防御性兜底。

当前 head f81295b6 的 Linux-CPU job 80505778292 失败不是这条 JIT 路径：它在 Build 阶段 extern_openvino configure 失败，还没进入 Test step，也没跑到 custom op JIT / cache cleanup。因此这轮 Linux-CPU 失败目前按 unrelated build/infra 处理，我先不盲目 rerun，等其它 checks 继续给信号。

codecov-commenter · 2026-06-10T10:30:22Z

Codecov Report

❌ Patch coverage is 90.00000% with 5 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (develop@255dd8e). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...thon/paddle/utils/cpp_extension/extension_utils.py	91.89%	3 Missing ⚠️
python/paddle/utils/cpp_extension/cpp_extension.py	84.61%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             develop   #79293   +/-   ##
==========================================
  Coverage           ?   90.00%           
==========================================
  Files              ?        2           
  Lines              ?       50           
  Branches           ?        0           
==========================================
  Hits               ?       45           
  Misses             ?        5           
  Partials           ?        0

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

SigureMo · 2026-06-10T10:36:51Z

@ShigureNyako 再分析下 Linux CPU 为啥编译一直挂吧，又出新问题了，但是看起来和这个 PR 无关啊，找找其他通过的 PR 日志对比一下吧，这 CI 真离谱啊

ShigureNyako · 2026-06-10T10:58:42Z

@SigureMo 我把这轮 Linux-CPU 编译失败和几个通过/半通过日志对了一下，结论是：当前这个失败边界在 extern_openvino 的 ExternalProject configure，和本 PR 的 cpp_extension / JIT cache 改动无关，也还没进 Test 阶段。

当前失败 job 80518667663：

失败发生在 bash ${ci_scripts}/run_setup.sh bdist_wheel 的 Build 阶段；还没进入 Linux-CPU Test step，所以也没有执行到本 PR workflow 里 rm -rf /root/.cache/paddle_extensions 那段。

具体失败点是：

FAILED: third_party/openvino/src/extern_openvino-stamp/extern_openvino-configure
CMake Error at .../extern_openvino-configure-Release.cmake:49 (message):
  Command failed: 1

前面的 OpenVINO patch 已经到固定 commit 07ecdf07d2974410dc1d67d9fa2d3433dcab7865；失败是在后续 configure。GitHub job log 只提示看 /paddle/build/third_party/openvino/src/extern_openvino-stamp/extern_openvino-configure-*.log，但这份内部 configure log 没有被上传，所以公开日志里看不到 OpenVINO CMake 内部的第一因。

对比通过日志：

80404721798：同一个 Linux-CPU docker image ccr-2vdh3abv-pub.cnc.bj.baidubce.com/ci/paddle:19d3669ca5ff0b19144a785bb3126d7e，同一个 OpenVINO commit 07ecdf07d...，同一类 configure 命令；日志是 -- extern_openvino configure command succeeded，后面继续 build/install/test 并通过。
80463617399 也是同样通过。
80489865567（今天 05:48 左右）OpenVINO configure/build/install 也成功了，后面才是测试失败，说明至少到那时 Linux-CPU 的 OpenVINO build 路径本身还能跑通。

横向看近期失败：06-10 07:12 之后多条无关 PR 的 Linux-CPU 都在类似位置挂过（例如 80502018615、80519800403、80523034944、80524064994、80530767527、80518667663），也夹杂有 Downloading Paddle.tar.gz 阶段 exit 4 的 artifact/网络失败。这些 PR 的改动范围不重合，但失败镜像、OpenVINO 固定 commit 和 configure 命令基本一致。

所以我现在把这次 Linux-CPU 判为 CI 基础环境 / 外部依赖 / runner cache 类问题：能确认的边界是 extern_openvino configure 内部返回 1；不是 Paddle C++ 编译错误，不是 custom op JIT，也不是本 PR 要修的 build.ninja / paddle_extensions cache 问题。当前我不改 PR，也先不盲目 rerun，等最后一个还在跑的 Linux-DCU 结束后再统一处理这轮 unrelated failures。

SigureMo · 2026-06-10T11:02:06Z

当前我不改 PR，也先不盲目 rerun，等最后一个还在跑的 Linux-DCU 结束后再统一处理这轮 unrelated failures。

你不用处理啊，你就分析下，到底是为啥，要怎么修

ShigureNyako · 2026-06-10T11:03:35Z

@SigureMo 当前这一轮 CI 已基本结束，我把剩下两个失败也归类了一下：

Linux-CPU / Build and test（job 80518667663）：还是在 Build 阶段挂掉，失败点是 third_party/openvino/src/extern_openvino-stamp/extern_openvino-configure：
```
CMake Error at .../extern_openvino-configure-Release.cmake:49 (message):
  Command failed: 1
ninja: build stopped: subcommand failed.
```
这一步发生在 run_setup.sh bdist_wheel，还没进 Test step，因此仍然没有执行到本 PR 里的 rm -rf /root/.cache/paddle_extensions / run_linux_cpu_test.sh，也没有跑到 custom op JIT 测试。这个结果不能验证/否定本 PR 的 JIT cache 修复。
CE-Framework / Infer（job 80512024437）：失败是下载测试模型/资源时网络不可达：
```
urllib.error.URLError: <urlopen error [Errno 101] Network is unreachable>
paddle-qa.bj.bcebos.com
```
和本 PR 的 cpp_extension 变更无关。

我尝试对这两个 workflow run 执行 gh run rerun --failed，但 GitHub 返回：

Must have admin rights to Repository.

所以这边没法直接触发 rerun。当前代码侧没有新增可处理项；需要等有权限的账号重跑失败 job 后看 Linux-CPU 是否能真正进入 Test 阶段。

ShigureNyako · 2026-06-10T11:15:54Z

@SigureMo 明白，我先不说 rerun/处理，只说“为什么”和“怎么修”。我重新把当前 #79293 和旁边几个 Linux-CPU compile fail 分开看了一下，至少是两类问题：

[CI] Fix C++ extension JIT cache invalidation #79293 当前 Linux-CPU job 80518667663
- 能确认的失败边界是 extern_openvino 的 ExternalProject configure：
```
FAILED: third_party/openvino/src/extern_openvino-stamp/extern_openvino-configure
CMake Error at .../extern_openvino-configure-Release.cmake:49 (message):
  Command failed: 1
```
- 这不是 Paddle C++ 编译报错，也不是 custom op JIT / paddle_extensions；还没到 Test step。
- 但“OpenVINO configure 里面具体哪条 CMake check 挂了”现在从 GitHub 公共日志看不到，因为 Paddle 全局 EXTERNAL_PROJECT_LOG_ARGS 对 configure 开了 LOG_CONFIGURE 1，真实 stdout/stderr 被写到：
```
/paddle/build/third_party/openvino/src/extern_openvino-stamp/extern_openvino-configure-*.log
```
  job 失败时没有 cat/upload 这份文件。
- 所以这个问题的修法我认为应先是 CI 诊断修复：Build 失败时把 build/third_party/*/src/*-stamp/*-configure-*.log 至少 extern_openvino-configure-*.log 打到日志或上传 artifact，或者对 OpenVINO 暂时关掉 LOG_CONFIGURE。没有这份内部 log，就不能负责任地说 OpenVINO 到底缺哪个包/哪个 CMake 条件失败。
另一些“Linux-CPU 编译挂”的新问题（例如 [Fix] fix Linux CPU CI tests fail #79298 的 job 80533739586）
- 这个有明确第一因，不是 OpenVINO：
```
/paddle/third_party/gloo/gloo/transport/tcp/device.cc:152:39: error:
  aggregate ‘std::array<char, 64> hostname’ has incomplete type and cannot be defined
```
- 这是 Gloo 源里用 std::array 但旧源/旧 submodule 没带 <array>，在 GCC 13 下暴露。
- 当前 develop 的 third_party/gloo 已是 54953de0643a0977a63a79756510739145a681e6，这个版本的 device.cc 已经有 #include <array>；[Fix] fix Linux CPU CI tests fail #79298 的 diff 里还带了 third_party/gloo / third_party/sleef 的 submodule 变更/删除，所以它会先在 Gloo 编译处挂。
- 修法是撤掉这些误带的 submodule 变更或 rebase/merge develop，让 Gloo 回到 54953de...；如果必须在旧分支上修，就是给 gloo/transport/tcp/device.cc 补 #include <array>，或者 cherry-pick [ThirdParty] Update gloo and remove local patch application #79245 的 Gloo update。

所以我现在的判断是：#79293 这轮是 OpenVINO configure 内部失败，但关键内部 log 没暴露，修 CI 日志/上传后才能定位具体 OpenVINO 原因；#79298 这类新 compile fail 则已经能确定是旧/误改 Gloo submodule 在 GCC 13 下缺 <array>。这两个和本 PR 的 cpp_extension / JIT cache 修复都不是同一个问题。

SigureMo · 2026-06-10T11:25:18Z

修法是撤掉这些误带的 submodule 变更或 rebase/merge develop，让 Gloo 回到 54953de...；如果必须在旧分支上修，就是给 gloo/transport/tcp/device.cc 补 #include ，或者 cherry-pick #79245 的 Gloo update。

啥意思？你是说别人的 PR 导致我们的 PR 是挂的？？？？？？@swgu98 出来！

ShigureNyako · 2026-06-10T11:30:39Z

@SigureMo 不是，我上一条把两个现象放一起说得容易误解了，先澄清：没有证据表明 #79298 或其它未合入 PR 导致 #79293 挂。

#79293 这轮 Linux-CPU 的证据是：

[CI] Fix C++ extension JIT cache invalidation #79293 diff 只改了：
- .github/workflows/_Linux-CPU.yml
- python/paddle/utils/cpp_extension/*
- test/cpp_extension/test_cpp_extension_ninja.py
  没有改 third_party/gloo / third_party/sleef。
[CI] Fix C++ extension JIT cache invalidation #79293 的 third_party/gloo 是 develop 上的 54953de0643a0977a63a79756510739145a681e6。

job 80518667663 里 Gloo 实际已经 build/install completed：

Completed 'extern_gloo'

后面才挂在：

FAILED: third_party/openvino/src/extern_openvino-stamp/extern_openvino-configure

所以 #79298 那个 Gloo 缺 <array> 只是“另一个 Linux-CPU compile fail 的例子”，不是 #79293 的原因；#79298 现在也是 OPEN，未合入 develop，不会进入 #79293 的 merge ref。#79298 自己的 diff 里带了 third_party/gloo / third_party/sleef submodule 变化，所以它是它自己的问题。

#79293 当前真正能定位到的是：OpenVINO ExternalProject configure wrapper 返回 1，但内部原因被 LOG_CONFIGURE 收到 extern_openvino-configure-*.log 里，公共 job log 没打出来。因此现在不能把它归因到某个 PR；更像是 Linux-CPU 公共 CI 环境 / runner cache / OpenVINO configure 内部条件的问题。要继续查 #79293 的第一因，需要把那份 extern_openvino-configure-*.log 打出来或上传。这里我前面表述不够清楚，抱歉。

ShigureNyako · 2026-06-10T13:44:34Z

@SigureMo 补一轮 authorized rerun 结果：head f81295b6 的 Linux-CPU job 80559589452 已经跑完并通过。

关键证据：

Build 阶段这次通过了 extern_openvino configure / build / install，说明上一轮 80518667663 的 OpenVINO configure fail 不是本 PR 稳定复现的问题。
Test 阶段跑到了之前关注的 custom op JIT 路径：
- test_custom_simple_slice passed, 22.07s
- test_custom_extend_attrs_jit passed, 22.32s
- test_custom_inplace passed, 23.29s
没再看到 ninja -f /root/.cache/paddle_extensions/... SIGSEGV。
Linux-CPU 最终 check 是 success；中间只有 test_dataloader_dataset / test_nn_init_function timeout，rerun 后通过，属于这条流水线常见 flaky timeout。

另外注意到一个小现象：Test 前的 rm -rf /root/.cache/paddle_extensions 在共享 cache 上仍打出过 Directory not empty（custom_inplace / custom_extend_attrs_jit/__pycache__），说明这个 CFS cache 确实有并发/残留状态，workflow cleanup 只能算防御兜底；本轮真正验证到的是代码侧 cache invalidation 修复可以让目标 JIT 测试通过。

当前剩余非通过 checks 只是还在跑（PR-CI-SOT / Linux-DCU / Linux-NPU），暂时没有新的失败；我先不再改代码或重跑。

ShigureNyako · 2026-06-10T15:02:11Z

@SigureMo 最后一轮 CI 状态更新：head f81295b6 目前可见 checks 已全部通过，没有失败/仍在跑的 check。

关键项：

CE-Framework / Infer rerun 通过。
Linux-CPU / Build and test rerun 通过；其中已跑到并通过之前关注的 custom op JIT 测试，且未再出现 ninja SIGSEGV：
- test_custom_simple_slice
- test_custom_extend_attrs_jit
- test_custom_inplace
Linux-DCU / Test 最后也通过了。

当前 PR 只剩 review gate。

[CI] Clear Linux-CPU extension JIT cache before tests

ca41e50

Co-authored-by: Codex <noreply@openai.com>

ShigureNyako commented Jun 10, 2026

View reviewed changes

ShigureNyako mentioned this pull request Jun 10, 2026

[Typing] Upgrade mypy to 2.1.0 and target Python 3.10 #79289

Merged

[CI] Fix C++ extension JIT cache invalidation

f81295b

Co-authored-by: Codex <noreply@openai.com>

ShigureNyako changed the title ~~[CI] Clear Linux-CPU extension JIT cache before tests~~ [CI] Fix C++ extension JIT cache invalidation Jun 10, 2026

paddle-bot Bot added the contributor External developers label Jun 10, 2026

Conversation

ShigureNyako commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Category

PR Types

Description

是否引起精度变化

Uh oh!

ShigureNyako left a comment

Choose a reason for hiding this comment

Uh oh!

SigureMo commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

SigureMo commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

codecov-commenter commented Jun 10, 2026

Codecov Report

Uh oh!

SigureMo commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

SigureMo commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

SigureMo commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

ShigureNyako commented Jun 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ShigureNyako commented Jun 10, 2026 •

edited

Loading