[WIP][CI] Enable DCU C++20 toolchain baseline#79421
Conversation
There was a problem hiding this comment.
Pull request overview
This PR advances the DCU CI C++20 toolchain baseline by upgrading the DTK develop Docker image compiler from GCC 8.2 to GCC 12.2 and switching HIP compilation flags from C++17 to C++20, aligning DCU with the broader C++20 migration plan discussed in #79384.
Changes:
- Update
tools/dockerfile/Dockerfile.develop.dtkto install/usegcc122and repointgcc/g++symlinks andPATHto/usr/local/gcc-12.2. - Update
cmake/hip.cmaketo use-std=c++20for HIP compilation flags (was-std=c++17).
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tools/dockerfile/Dockerfile.develop.dtk | Switch DCU DTK image GCC toolchain from 8.2 to 12.2 via existing install script and updated symlinks/PATH. |
| cmake/hip.cmake | Change HIP compilation standard flag from C++17 to C++20. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| list(APPEND HIP_CXX_FLAGS -Wno-pessimizing-move) | ||
| list(APPEND HIP_CXX_FLAGS -std=c++17) | ||
| list(APPEND HIP_CXX_FLAGS -std=c++20) | ||
| list(APPEND HIP_CXX_FLAGS --gpu-max-threads-per-block=1024) |
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
发现一个需要先处理的非行级问题；本轮没有可挂到变更行的 inline 评论。
优先级：P1 非行级：问题在
.github/workflows/docker.yml，该文件不在本 PR 的 changed diff 中，无法挂到变更行。当前 PR 将Dockerfile.develop.dtk改为 GCC 12.2 后，文件实际 md5 为881e30f7ca65be3eb3c04ea34e44c030，但 Docker 构建流程对docker_dcu仍强制使用固定 tag76937a563116f6008c8ca4cb4f592759，覆盖了按 Dockerfile 计算出的 md5。这样 DCU CI 继续拉取旧的固定镜像，gcc122变更不会进入实际 DCU 构建环境，-std=c++20的验证也不会覆盖目标工具链。请同步更新/移除该固定覆盖，并触发真实 DCU Docker 构建与 Linux-DCU 验证；修复形态例如：# .github/workflows/docker.yml md5_value=$(md5sum tools/dockerfile/${docker_files[$name]} | awk '{print $1}') # 不再对 docker_dcu 覆盖为旧固定值，或将固定值更新为新镜像并确保已重新构建推送
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
CI报告基于以下代码生成（30分钟更新一次）: 1 Required任务 : 34/38 通过
2 失败详情🔴 Check PR Template / Check — PR问题（置信度: 高）错误类型: PR问题 | 置信度: 高
关键日志:
修复建议:
关联变更: PR body 字段，不涉及代码文件。 🔴 Check PR Template / Check — PR问题（置信度: 高）错误类型: PR问题 | 置信度: 高
关键日志:
修复建议:
关联变更: PR body 字段，不涉及代码文件。 🔴 Model-Benchmark / Benchmark test — 环境问题（置信度: 中）错误类型: 环境问题 | 置信度: 中
关键日志:
修复建议:
关联变更: 未发现直接关联；PR 修改集中在 |
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查新提交，之前关于 docker_dcu 镜像 tag 固定覆盖的 P1 问题已解决：当前流程会直接使用 Dockerfile.develop.dtk 的内容 md5 生成 DCU 镜像 tag，GCC 12.2 的 Dockerfile 变更可以进入实际镜像构建路径。
本轮未发现新的需要阻塞合入的问题。当前 CI 仍有任务在运行，最终合入前请以完整 CI 结果为准。
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查最新提交。之前关于 docker_dcu 固定旧 tag 的问题仍保持解决状态，但本次新增的 install_gcc.sh 修复没有进入当前 DCU 镜像 cache key，可能导致 CI 继续复用上一轮镜像而跳过这次脚本修复。
具体问题已放在 inline review comment 中；请修复后提交新的 commit 再复查。
| @@ -109,9 +109,6 @@ jobs: | |||
| for name in "${!docker_files[@]}" | |||
| do | |||
| md5_value=`md5sum tools/dockerfile/${docker_files[$name]} | awk '{print $1}'` | |||
There was a problem hiding this comment.
处理要求：请针对该评论修复并提交新的 commit。
这里仍然只用 Dockerfile.develop.dtk 的内容 md5 作为 docker_dcu 镜像 tag，但当前最新提交只修改了 tools/dockerfile/build_scripts/install_gcc.sh，Dockerfile.develop.dtk 的 md5 仍是上一轮的 881e30f7ca65be3eb3c04ea34e44c030。由于该 Dockerfile 通过 COPY tools/dockerfile/build_scripts /build_scripts 引入脚本，现有逻辑会继续拉取同一个 docker_dcu 镜像 tag；如果上一轮镜像已存在，docker pull 成功后就不会重新 build，install_gcc.sh 的 Kylin/lib64 修复不会进入实际 DCU 镜像，也无法验证本 PR 的目标环境。
建议把 docker_dcu 实际 COPY 的脚本也纳入 cache key，或采用等价方式确保 build_scripts 变更会触发 DCU 镜像重建。一个最小修复形态如下：
| md5_value=`md5sum tools/dockerfile/${docker_files[$name]} | awk '{print $1}'` | |
| if [ "$name" == "docker_dcu" ]; then | |
| md5_value=`md5sum tools/dockerfile/${docker_files[$name]} tools/dockerfile/build_scripts/install_gcc.sh | md5sum | awk '{print $1}'` | |
| else | |
| md5_value=`md5sum tools/dockerfile/${docker_files[$name]} | awk '{print $1}'` | |
| fi |
There was a problem hiding this comment.
处理要求：请针对该评论修复并提交新的 commit。
补充当前 head ab2a5596fd175cdcda2edfac405d727be77b19cd 的复查结果：Dockerfile.develop.dtk 现在又回到 md5 881e30f7ca65be3eb3c04ea34e44c030，而 install_gcc.sh 仍是修改后的 a6ec0a16bc1ebde45ea6f329c87638d1。因此 docker_dcu 仍只会生成旧的 Dockerfile tag，若该 tag 已存在就会复用旧镜像，install_gcc.sh 的最新修复仍无法保证进入实际 DCU 镜像。请把 install_gcc.sh/build_scripts 纳入 docker_dcu hash，或用等价方式确保脚本变更触发新的镜像 tag。
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查最新提交。此前关于 install_gcc.sh 变更未触发 DCU 镜像重建的 P1 问题已解决：当前 Dockerfile.develop.dtk 自身也发生变化，md5 从上一轮的 881e30f7... 更新为 968946be...，因此 docker_dcu 会使用新的镜像 tag，最新脚本内容会进入重建路径。
本轮未发现新的需要阻塞合入的问题。当前 CI 仍在运行，最终合入前请以完整 CI 结果为准。
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查最新提交。Dockerfile.develop.dtk 又恢复到旧 md5，而 install_gcc.sh 仍有新内容，之前关于 docker_dcu 镜像 cache key 未覆盖脚本变更的 P1 问题重新成立。
我已在原 inline thread 中补充当前 head 的新证据；请修复后提交新的 commit 再复查。
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查最新提交。此前关于 install_gcc.sh 变更未触发 docker_dcu 镜像重建的 P1 问题已解决：当前 Dockerfile.develop.dtk 内容变更后 md5 为 11d511e0ec10d02e38b816953ba4ebfa，会生成新的 DCU 镜像 tag。
本轮发现一个新的 workflow 阻塞问题，详情已放在 inline review comment 中；请修复后提交新的 commit 再复查。当前 CI 仍在运行，最终状态也请以完整 CI 结果为准。
| @@ -109,9 +109,6 @@ jobs: | |||
| for name in "${!docker_files[@]}" | |||
| do | |||
| md5_value=`md5sum tools/dockerfile/${docker_files[$name]} | awk '{print $1}'` | |||
There was a problem hiding this comment.
处理要求：请针对该评论修复并提交新的 commit。
删除 docker_dcu 固定 md5 后，这里的 md5sum tools/dockerfile/${docker_files[$name]} 也会在 inputs.is_merge == "true" 的路径执行。该路径上面只下载 ci_dockerfile.sh 和 Dockerfile.ubuntu20，而 ci_dockerfile.sh 只生成 CPU/SOT/build/coverage 相关 Dockerfile，不会生成 Dockerfile.develop.dtk，也没有 tools/dockerfile/build_scripts；默认 task=cpu 的 docker_files 仍包含 docker_dcu。因此 merge-mode 会先得到空 md5，再尝试 docker build -f tools/dockerfile/Dockerfile.develop.dtk .，最终因为 Dockerfile/构建上下文缺失而失败。
请让 merge-mode 的 docker_dcu 路径也有完整输入，或在该模式下显式复用已有 DCU tag。一个可实现的修复形态如下：
if [ "${{ inputs.is_merge }}" == "true" ]; then
mkdir -p tools/dockerfile/build_scripts
cd tools/dockerfile
wget -q --tries=5 --no-proxy \
${dockerfile_script} \
${dockerfile_origin} \
https://raw.githubusercontent.com/PaddlePaddle/Paddle/refs/heads/develop/tools/dockerfile/Dockerfile.develop.dtk \
--no-check-certificate
cd build_scripts
wget -q --tries=5 --no-proxy \
https://raw.githubusercontent.com/PaddlePaddle/Paddle/refs/heads/develop/tools/dockerfile/build_scripts/install_gcc.sh \
--no-check-certificate
cd ..
else
...
fi
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查最新提交。此前 .github/workflows/docker.yml 中 merge-mode 的 docker_dcu 构建输入缺失问题仍未修复，继续以原 inline thread 为准。
本轮新增发现一个 GCC runtime 隔离改动带来的阻塞问题，详情已放在新的 inline review comment 中；请修复后提交新的 commit 再复查。当前 CI 还有任务在运行，且 PR 模板检查失败也需要作者同步处理。
| lib_so_6=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 | ||
| lib_path=/usr/lib/x86_64-linux-gnu | ||
| fi | ||
| # GCC is installed side-by-side. Callers select its runtime via LD_LIBRARY_PATH. |
There was a problem hiding this comment.
处理要求：请针对该评论修复并提交新的 commit。
这里把 install_gcc.sh 改成只做 side-by-side 安装后，所有使用 GCC 12.x 的调用方都需要显式选择对应 runtime；但 tools/dockerfile/ci_dockerfile.sh 生成 Dockerfile.cuda123_cudnn9_gcc122_ubuntu20 时仍只把编译器路径从 GCC 8.2 改成 GCC 12.1，没有加入 /usr/local/gcc-12.1/lib64。我用当前脚本生成后看到该 Dockerfile 只有：
RUN bash /build_scripts/install_gcc.sh gcc121
ENV PATH=/usr/local/gcc-12.1/bin:$PATH
在本次提交之前，install_gcc.sh gcc121 会替换系统 libstdc++.so.6，所以这个生成路径还能拿到 GCC 12.1 runtime；现在该副作用被删除，CI 的 distribute 镜像会使用 GCC 12.1 编译器但运行/链接时仍落到 Ubuntu 20.04 系统 libstdc++，容易触发 GLIBCXX_* 符号缺失或运行时 ABI 不一致。
请同步修复 ci_dockerfile.sh 的 GCC 12.1 生成路径，例如在替换 PATH 时同时插入 runtime 路径：
sed -i 's#PATH=/usr/local/gcc-8.2/bin:$PATH#PATH=/usr/local/gcc-12.1/bin:$PATH#g' ${dockerfile_name}
sed -i '/ENV PATH=\/usr\/local\/gcc-12.1\/bin:$PATH/a ENV LD_LIBRARY_PATH=/usr/local/gcc-12.1/lib64:/usr/local/gcc-12.1/lib:${LD_LIBRARY_PATH}' ${dockerfile_name}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
@gouzil 这个报错目前看不是一次性 flaky。该 job 基于旧 head 当前 head |
|
@ShigureNyako 来 review 一下，重点看一下 install gcc 那块，还有 docker 环境变量设置的那块 |
|
@gouzil 已按当前 head
CI 方面，最新有效的 PR template Check 已通过；Fleet single-card 和 Model-Benchmark 的失败均已跨 rerun 稳定复现，但不经过上述 GCC 12.1 distribute 路径，与本 PR 改动无因果关系。最新 Linux-DCU Build 的核心编译和产物上传成功，但 job 在 cleanup 阶段被取消，Test 随后 skipped，因此还没有当前镜像的 DCU runtime 测试结论。 |
gouzil
force-pushed
the
codex/dcu-cxx20-toolchain
branch
from
4255e12 to
3cf11c1
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查最新提交。此前两个 P1 问题仍未解决，继续以原有 inline thread 为准：merge-mode 的 DCU Dockerfile/构建上下文缺失，以及 ci_dockerfile.sh 的 GCC 12.1 runtime 路径缺失。
本轮在 DCU test 容器清理改动里发现一个新的阻塞问题，详情已放在 inline review comment 中；请修复后提交新的 commit 再复查。当前 CI 仍在运行，最终状态也请以完整 CI 结果为准。
| ' | ||
| docker stop ${container_name} | ||
| docker rm ${container_name} | ||
| docker rm -f "${container_name}" |
There was a problem hiding this comment.
处理要求：请针对该评论修复并提交新的 commit。
这里直接删容器会把 DCU test 的宿主机 workspace 留在原地：上面的 docker run 把 ${{ github.workspace }} bind 到 /paddle，而当前启动时只清理同名旧容器，不清理 workspace；Download build.tar.gz 也只执行 rm -rf ./*，不会删除 .git、.pytest_cache 等隐藏目录。这样一次失败/取消后的隐藏文件会跨 run 留在自托管 DCU runner 上，后续解包 build.tar.gz 时可能混入旧状态，导致测试结果不可复现。
请保留有上限的 workspace 清理，再强制删除容器，避免清理卡住但仍清掉 bind mount 内容。例如恢复成：
| docker rm -f "${container_name}" | |
| if [[ -n "${container_name:-}" ]]; then | |
| timeout 10m docker exec -t "${container_name}" /bin/bash -c ' | |
| rm -rf * .[^.]* | |
| ' || true | |
| docker rm -f "${container_name}" | |
| fi |
There was a problem hiding this comment.
处理要求：请针对该评论修复并提交新的 commit。
这版已经恢复了 bind mount workspace 的清理，但当前写法仍不满足“清理有上限且最终强制删除容器”的要求：set -e 之后先执行 docker exec ... rm -rf * .[^.]*，一旦这个清理命令失败或卡住，后面的 docker rm -f "${container_name}" 就不会执行。这样失败/取消路径仍可能留下同名 DCU 容器，并且 cleanup step 会被无上限的 workspace 删除阻塞。
请把 workspace 清理和强制删容器解耦：给 docker exec 加 timeout，记录清理状态，但无论清理是否失败都执行 docker rm -f。如果希望保留 workspace 清理失败状态，可以用类似下面的结构：
cleanup_status=0
timeout 10m docker exec -t "${container_name}" /bin/bash -c 'rm -rf * .[^.]*' || cleanup_status=$?
docker rm -f "${container_name}"
exit "${cleanup_status}"
There was a problem hiding this comment.
补充 current head d563602 的实际 CI 证据：Linux-DCU / Build 的下载、编译和 BOS 上传步骤都已成功，Terminate and delete the container 从 17:46:16Z 开始后一直未完成；该 job 配置 timeout-minutes: 180，最终在约 180 分钟上限及取消宽限后于 20:23:47Z 被取消，Test 随后 skipped。
也就是说，当前无上限的 cleanup step 实际占满了剩余 job 时间，已经复现了这里描述的问题。仍需要给 workspace 清理加 timeout，并确保无论清理结果如何都会执行 docker rm -f。
There was a problem hiding this comment.
处理要求：请针对该评论修复并提交新的 commit。
确认，这个 CI 结果已经把风险从理论路径变成了实际复现：Linux-DCU / Build 的下载、编译和 BOS 上传步骤都已完成，job 最后停在 Terminate and delete the container，并因 3 小时上限失败，后续 Test 被跳过。
当前修复需要同时满足两点：给 workspace 清理设置有界 timeout，并且无论 docker exec 清理结果如何都执行 docker rm -f。可以按下面的结构处理，修复后请用新 head 的 Linux-DCU Build/Test 再确认 cleanup 不再耗尽 job timeout。
cleanup_status=0
timeout 10m docker exec -t "${container_name}" /bin/bash -c 'rm -rf * .[^.]*' || cleanup_status=$?
docker rm -f "${container_name}"
exit "${cleanup_status}"
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
gouzil
force-pushed
the
codex/dcu-cxx20-toolchain
branch
from
3cf11c1 to
451581e
Compare
risemeup1111
left a comment
risemeup1111
left a comment
There was a problem hiding this comment.
已复查新提交。DCU cleanup 这次恢复了 bind mount workspace 清理，但当前实现仍会在清理失败或卡住时跳过强制删容器，我已在原 cleanup 线程补充了当前代码证据和建议修复形态。
此前两个 P1 问题仍未由本次提交修复，继续以原有 inline thread 为准：merge-mode 的 DCU Dockerfile/构建上下文缺失，以及 ci_dockerfile.sh 的 GCC 12.1 runtime 路径缺失。请修复后提交新的 commit 再复查。
PaddlePaddle-bot
left a comment
PaddlePaddle-bot
left a comment
There was a problem hiding this comment.
🤖 Paddle-CI-Agent | pr_review |
2026-07-14 01:18:19
📋 Review 摘要
PR 概述：推进 DCU C++20 工具链 baseline，并调整 DCU Docker/CI 清理与 GCC runtime 选择。
变更范围：DCU GitHub Actions、Docker 镜像生成脚本、GCC 安装脚本和 HIP CMake flags。
影响面 Tag：[Execute Infrastructure] [Environment Adaptation]
问题
| 级别 | 文件 | 概述 |
|---|---|---|
| 🟡 建议 | .github/workflows/_Linux-DCU.yml:192 |
build 清理块在 docker exec 失败时不会继续执行 docker rm -f |
| 🟡 建议 | .github/workflows/_Linux-DCU.yml:308 |
test 清理块存在同样的强制删除容器被 set -e 跳过的风险 |
历史 Findings 修复情况
| Finding | 问题 | 状态 |
|---|---|---|
| F1 | 删除 docker_dcu 固定 md5 后，is_merge=true 分支会尝试对一个没有下载的 Dockerfile.develop.dtk 计算 md5。 |
|
| F2 | 这里只把 CMake hip_add_* 路径切到了 -std=c++20，但 DCU/HIP 的运行时编译路径仍会用 C++17。 |
|
| F3 | 这里把 install_gcc.sh 改成要求调用方通过 LD_LIBRARY_PATH 选择 runtime，但仍有 GCC 12.1 调用方没有同步设置 runtime 路径。 |
🔄 部分修复 |
| F4 | 这里删掉 test job 的 workspace 清理后，下一次 DCU test 只会清理非隐藏文件。 | ✅ 已修复 |
📝 PR 规范检查
标题不符合当前模板枚举：[WIP][CI] 不是 §D2 中的 PR Category / PR Types；描述结构包含四个必填 section，且精度变化填写为 否。
标题建议（可直接复制）：
[Execute Infrastructure] Enable DCU C++20 toolchain baseline
PR 描述建议（点击展开，可直接复制）
### PR Category
<!-- One of [ User Experience | Execute Infrastructure | Operator Mechanism | CINN | Custom Device | Performance Optimization | Distributed Strategy | Parameter Server | Communication Library | Auto Parallel | Inference | Environment Adaptation ] -->
Execute Infrastructure
### PR Types
<!-- One of [ New features | Bug fixes | Improvements | Performance | BC Breaking | Deprecations | Docs | Devs | Not User Facing | Security | Others ] -->
Improvements
### Description
<!-- Describe what you’ve done -->
跟进任务 issue：https://github.com/PaddlePaddle/Paddle/issues/79384
本 PR 按最小范围推进 DCU C++20 baseline：
- 将 `tools/dockerfile/Dockerfile.develop.dtk` 中的 DCU DTK 开发镜像 GCC 安装从 `gcc82` 切换为 `gcc122`，并同步更新 `gcc/g++` symlink 与 `PATH` 到 `/usr/local/gcc-12.2/bin`。
- 将 `cmake/hip.cmake` 中的 HIP 编译参数从 `-std=c++17` 切换为 `-std=c++20`。
当前保留 `[WIP]`：还需要在真实 DCU CI / DTK 24.04.1 环境里验证 HIP 编译器和设备编译链路对 C++20 的兼容性。本地未执行完整 DTK 镜像构建和 DCU 编译验证。
验证：
- `prek`
- `prek run --files cmake/hip.cmake tools/dockerfile/Dockerfile.develop.dtk`
- `git diff --check upstream/develop...HEAD`
### 是否引起精度变化
<!-- one of the following [ 是 | 否 ]-->
否总体评价
本轮新增问题集中在 DCU 容器清理的失败路径；其余已按当前代码核对历史 finding 状态。由于 F1/F2 仍存在且 F3 仍未完全覆盖所有 GCC 12.1 调用方，建议合入前继续修正这些 CI/Docker 链路问题。
| docker stop ${container_name} | ||
| docker rm ${container_name} | ||
| set -e | ||
| docker exec -t "${container_name}" /bin/bash -c 'rm -rf * .[^.]*' |
There was a problem hiding this comment.
🟡 建议 这里在 set -e 下先执行 docker exec，一旦容器已经退出或 exec 失败，脚本会直接中断，后面的 docker rm -f 就不会执行。
这会和本次改动想要强制清理遗留容器的目标相反，失败场景下仍会把容器留在 runner 上。建议恢复类似原来的兜底顺序：记录 docker exec 的失败状态，但无论如何都先执行 docker rm -f，最后再返回清理状态。
| docker stop ${container_name} | ||
| docker rm ${container_name} | ||
| set -e | ||
| docker exec -t "${container_name}" /bin/bash -c 'rm -rf * .[^.]*' |
There was a problem hiding this comment.
🟡 建议 test job 这里也有同样的清理顺序问题：docker exec 在 set -e 下失败时，后续的 docker rm -f 不会执行。
建议和 build job 保持一致，先容忍/记录 workspace 清理失败，再保证执行 docker rm -f "${container_name}"，避免失败测试留下同名容器影响后续 DCU 任务。
|
你的PR提交成功，感谢你对开源项目的贡献! |
PR Category
Execute Infrastructure
PR Types
Improvements
Description
跟进任务 issue：#79384
该 issue 的 C++20 CI 工具链升级清单中，DCU CI 仍使用 GCC 8.2，HIP 编译参数仍固定为 C++17。本 PR 按最小可验证路径推进 DCU C++20 baseline：
-std=c++17切换为-std=c++20。docker_dcu镜像 tag 的固定 md5 覆盖，使 Dockerfile 变化能够触发镜像重建。install_gcc.sh调整为仅把 GCC 安装到独立目录，不再备份、删除或替换系统libstdc++.so.6。LD_LIBRARY_PATH显式选择对应 GCC 运行时；Ubuntu GCC 8.2 变体继续使用兼容的系统运行时。download.sourcefind.cn。docker rm -f强制删除容器。最新 DCU CI 中
test_analyzer_capi_exp_pd_config在 GCC 12.2 产物上触发SIGILL。本次调整先消除安装器覆盖系统 C++ 运行时及混用libstdc++/libgcc_s的风险，仍需通过真实 DCU CI 确认最终结果，因此保留[WIP]。验证：
bash -n tools/dockerfile/build_scripts/install_gcc.sh tools/dockerfile/centos7_manylinux.sh tools/dockerfile/ubuntu20_release.shinstall_gcc.sh不再包含系统libstdc++备份、删除或软链逻辑prekgit diff --check本地未执行完整 DTK 镜像构建和 DCU 编译测试。
是否引起精度变化
否