Paddle CI C++20 工具链升级清单

[gouzil]

当前 develop 上已经有 C++20 baseline 的入口，但还不是“全链路 C++20”：

• Linux 主 CMake 在 cmake/flags.cmake 中对 GCC < 11 仍临时降级到 -std=c++17。
• Windows 在同一文件中无条件保持 CMAKE_CXX_STANDARD 17，理由是现有 CUDA/MSVC 组合还没有切到可接受 C++20 的版本。
• CUDA 目标在 cmake/cuda.cmake 中固定 CMAKE_CUDA_STANDARD 17。
• HIP、XPU device 编译、NVRTC/CINN JIT 等路径仍显式使用 c++17/c++14/c++11。

因此 CI 工具链升级的核心目标是：所有会编译 Paddle C++ 主体的 Linux CI 至少使用 GCC >= 11 或 Clang >= 14；GPU/Windows/异构设备链路需要同时升级到能接受 C++20 的 CUDA/HIP/MSVC/设备编译器组合，然后再移除 CMake 中的 C++17 fallback。

必须升级的 CI 链路

序号	优先级	链路	当前工具链证据	问题	建议目标	PR 链接
1	P0	CI-Build 的 Linux build/inference/static/CE/API/model/slice/deepmd 共享镜像	.github/workflows/docker.yml 把 docker_build_file 指向 Dockerfile.cuda11.2_cudnn8_gcc82_trt8；tools/dockerfile/ci_dockerfile.sh 实际从 nvidia/cuda:11.8.0-cudnn8-devel-ubuntu20.04 + Dockerfile.ubuntu20 生成，继承 GCC 8.2、Clang 12、TRT 8.5.3.1。	GCC 8.2 会触发 GCC < 11 的 C++17 fallback；CUDA 11.8 也不适合作为统一 C++20 GPU baseline。	生成新的 build 镜像，至少 CUDA 12.x + GCC 11/12+ + Clang 14+；更稳妥是和已有 CUDA 12.3/GCC12 或 CUDA 12.8+/TRT10 方向对齐。同步更新 docker.yml 的文件名和 ci_dockerfile.sh 的生成函数。	#79340
2	P0	Windows GPU / Windows Inference / Windows OPENBLAS	_Windows-GPU.yml 使用 VS2019 + CUDA 12.0；_Windows-Inference.yml 使用 VS2019 + CUDA 11.7 + TensorRT 8.0.1.6；_Windows-OPENBLAS.yml 未设置 vcvars64_dir，会落到 ci/windows/build.bat 的 VS2017 默认值；build.bat 默认还保留 CUDA 11.2 fallback。	cmake/flags.cmake Windows 分支仍固定 C++17；Inference 的 CUDA 11.7 和 OPENBLAS 的 VS2017 默认工具集都不满足全链路 C++20。	升级 runner 到 VS2022 工具集，并把 Windows GPU/Inference 统一到可验证 C++20 的 CUDA 12.x 组合，TensorRT 同步升到匹配版本；然后移除 Windows C++17 fallback。	#79381
3	P0	DCU CI	tools/dockerfile/Dockerfile.develop.dtk 基于 sugonhub/kylin:v10-dev，安装并切到 GCC 8.2；_Linux-DCU.yml 使用该 docker_dcu_image。	GCC 8.2 会触发 C++17 fallback；cmake/hip.cmake 还显式追加 -std=c++17。	与 DCU/ROCm SDK 能力确认后升级到 GCC >= 11/12，并验证 HIP 编译器对 C++20 的支持；随后把 HIP flags 从 C++17 切到 C++20。	待补充
4	P0	NPU CI	tools/dockerfile/Dockerfile.develop.npu 的基础镜像是 registry.baidubce.com/device/paddle-cpu:ubuntu20-npu-base-x86_64-gcc84。	基础镜像名显示 GCC 8.4，低于 C++20 baseline；实际编译器版本由外部镜像决定，当前 repo 无法证明其满足 C++20。	推出 gcc11/12+ 的 NPU base 镜像，确认 CANN/Ascend 工具链兼容后再让 NPU CI 纳入 C++20 baseline。	待补充
5	P1	release Ubuntu20 生成脚本	tools/dockerfile/ubuntu20_release.sh 对 CUDA 11.2、11.8 和 CPU 变体主动把 Dockerfile.release.ubuntu20 从 GCC 12.1 替换回 GCC 8.2。	发布/打包链路如果仍跑这些变体，会继续被 C++17 fallback 覆盖。	对仍需保留的 CUDA 11.x/CPU release 变体做取舍：升级到 CUDA 12.x/GCC12+，或明确标成 legacy 不进入 C++20 全链路。	待补充
6	P1	CentOS/manylinux 旧生成脚本	tools/dockerfile/centos7_manylinux.sh 的 CUDA 11.2/11.6/11.7/11.8 变体安装 GCC 8.2。	旧 manylinux/centos release 构建无法满足 C++20 baseline。	迁移到 tools/dockerfile/manylinux/Dockerfile 的 gcc-toolset-11 或更新的 CUDA 12/13 镜像；旧 CentOS 变体如必须保留，应从 C++20 gate 中剥离。	待补充

基本满足但要同步验证的链路

序号	链路	当前状态	后续动作	PR 链接
1	Linux CPU PR CI	ci_dockerfile.sh 的 CPU 镜像虽然文件名是 cuda9_cudnn7_gcc48_py35_centos6，实际从 Ubuntu 20.04 生成，并把 GCC 8.2 替换为 GCC 13。	文件名建议后续清理，避免误判；工具链本身满足 GCC >= 11。	待补充
2	SOT CI	Dockerfile.gcc133_ubuntu24_cpu_sot 基于 Ubuntu 24.04，安装系统 gcc/g++。	工具链方向正确；验证 runner 日志里实际 gcc --version。	待补充
3	Distribute-stable	Dockerfile.cuda123_cudnn9_gcc122_ubuntu20 使用 CUDA 12.3 + GCC 12.1 + cuDNN 9。	Host C++20 基本满足；如果要 CUDA device C++20，需要和 CMAKE_CUDA_STANDARD=20 一起验证。	待补充
4	Coverage / Night-Coverage	文件名仍是 Dockerfile.cuda117_cudnn8_gcc82_ubuntu18_coverage，但生成脚本实际从 Dockerfile.ubuntu22 + CUDA 12.0.1 + GCC 12 生成。	Host C++20 基本满足；建议改名并考虑与主 GPU baseline 统一到 CUDA 12.3+/12.8+。注意同步 gcov 版本，避免 coverage 采集错配。	待补充
5	XPU host CI	Dockerfile.develop.xre.ubuntu22 使用 GCC 12、Clang 14。	Host C++20 基本满足；但 XPU device/sysroot 仍是单独问题，见下一节。	待补充
6	macOS CI	CMake 要求 AppleClang >= 14；workflow 没有在 repo 内固定 Xcode 版本。	在 runner 上确认 clang --version 和 libc++ 可用特性；如果不满足，需要升级 Mac-CI runner/Xcode。	待补充
7	H-Coverage	workflow 使用 ubuntu24-cuda129-py312-dev 镜像名。	从名称看方向正确，但这是外部预构建镜像，需要在日志里确认 GCC/Clang/CUDA 实际版本。	待补充

非镜像但会阻断全链路 C++20 的点

这些不完全是“CI 工具链版本”，但升级 CI 后必须同步处理，否则仍不是全链路 C++20：

序号	位置	当前标准	影响	PR 链接
1	cmake/flags.cmake	Linux GCC < 11 降级到 -std=c++17；Windows 固定 C++17。	所有旧 GCC/Windows 链路升级后，需要移除 fallback，否则无法证明全链路 C++20。	待补充
2	cmake/cuda.cmake	CMAKE_CUDA_STANDARD 17。	CUDA .cu 目标仍按 C++17 编译；需要在 CUDA 12.x/13.x CI 中验证后切到 20。	待补充
3	cmake/hip.cmake	HIP flags 追加 -std=c++17。	DCU/ROCm 链路即使 host GCC 升级，也会保持 HIP C++17。	待补充
4	cmake/xpu_kp.cmake	XPU host sysroot 默认 /opt/compiler/gcc-8.2；device compile 使用 -std=c++11/-std=c++14。	XPU device 编译链路不属于当前 host C++20 baseline，需要单独和 XPU SDK 对齐。	待补充
5	NVRTC/CINN JIT 路径	paddle/phi/backends/device_code.cc、paddle/cinn/backends/nvrtc/nvrtc_util.cc、paddle/cinn/backends/compiler.cc 中仍有 c++17/c++14。	运行时 JIT/device code 不会自动跟随主工程 C++20，需要单独迁移和测试。	待补充

建议拆分顺序

1. 先升级 CI-Build 的共享 GPU build 镜像。
   这是影响面最大的瓶颈，覆盖 Linux build、Inference、Static-Check、CE、API benchmark、Model benchmark、Slice、DeepMD 等多数 PR build 链路。

2. 统一清理 Dockerfile 命名和生成脚本。
   当前 Dockerfile.cuda11.2... 实际是 CUDA 11.8，Dockerfile.cuda117...coverage 实际是 CUDA 12.0/GCC12，容易误导后续排查。

3. 升级 Windows 工具链。
   需要 runner、VS、CUDA、TensorRT 一起切，不建议只改 CMake 标准。

4. 升级 DCU/NPU/XPU device 相关链路。
   这些依赖厂商 SDK，比普通 Linux/GPU 更容易受 ABI、sysroot、设备编译器限制，建议按设备单独拆 PR。

5. 最后移除 C++17 fallback。
   当主 Linux、Windows、GPU、异构设备 CI 都有明确 C++20 工具链后，再删除 cmake/flags.cmake 的降级逻辑，并把 CUDA/HIP/JIT/device 标准逐步切到 C++20。

验证清单

• 生成 CI Dockerfile：cd tools/dockerfile && bash ci_dockerfile.sh。
• 检查生成文件中没有旧主链路工具链：rg "gcc-8.2|clang-12|cuda11|trt8" tools/dockerfile/Dockerfile.*。
• 每个升级后的 Docker 镜像在 CI 日志中打印并保存：
  • gcc --version
  • g++ --version
  • clang --version
  • cmake --version
  • nvcc --version 或对应设备编译器版本
  • gcov --version，仅 coverage 链路
• CMake 配置日志中不应再出现 GCC ... is temporarily downgraded to C++17。
• Windows 日志中确认 cl、nvcc、CUDA、TensorRT 版本，并确认 CMake 不再设置 C++17。
• Coverage 链路验证 gcov 与实际 GCC major 版本一致，避免 *.gcno 版本错配。