首页
/ OpenBLAS在LoongArch64和AMD64架构下使用GCC14的编译问题分析

OpenBLAS在LoongArch64和AMD64架构下使用GCC14的编译问题分析

2025-06-01 09:23:44作者:幸俭卉

问题概述

近期在Loongson-3A6000(LoongArch64架构)和AMD Zen4 7940HS(x86_64架构)平台上使用GCC14编译OpenBLAS时发现了两个关键问题。这些问题主要出现在特定编译环境下,值得开发者关注。

问题一:INTERFACE64模式下的测试失败

现象描述

当使用GCC14配合CMake构建系统,并启用INTERFACE64=1选项时,在两种架构上都出现了大量测试用例失败的情况。测试失败表现为段错误(Segmentation Fault)或总线错误(Bus error)。

环境细节

  • LoongArch64平台

    • 操作系统:Loong Arch Linux
    • 处理器:Loongson-3A6000
    • 内核版本:6.8.6-2或6.9.7-loongarch
    • GCC版本:14.1.0(源码编译)
  • AMD64平台

    • 操作系统:Debian GNU/Linux 12
    • 处理器:AMD Zen4 R9 7940HS
    • 内核版本:6.1.0-22-amd64
    • GCC版本:14.1.0(源码编译)

关键发现

  1. 使用GCC13及以下版本编译时,问题不会出现
  2. 不启用INTERFACE64=1选项时,编译和测试均正常
  3. 使用系统自带的GCC14(非源码编译版本)时,问题不会出现

技术分析

这个问题可能与GCC14的某些优化特性有关,特别是在处理64位接口时。由于使用系统自带的GCC14不会出现此问题,推测可能是特定编译配置导致的编译器行为差异。

问题二:LoongArch64特有的测试失败

现象描述

在LoongArch64平台上,无论是否启用INTERFACE64=1,使用GCC14编译后都会出现一个特定的测试失败:

TEST 99/103 potrf:smoketest_trivial [FAIL]
ERR: test_potrs.c:535 L s(0,0) difference: 1.19209e-07

测试期望的误差界限是1e-5,但实际误差1.19209e-07远小于此值却仍然报告失败。

解决方案

通过添加编译器优化指令可以解决此问题:

#pragma GCC optimize("no-gcse")

将此指令添加到test_potrs.c文件开头即可修复测试失败问题。

根本原因

这是GCC14.1版本中的一个编译器bug,特别是在LoongArch64平台上表现明显。该bug导致编译器在公共子表达式消除(GCSE)优化时产生了不正确的代码。值得注意的是,在GCC15的开发版本中这个问题已经被修复。

最佳实践建议

  1. 编译器选择

    • 对于生产环境,建议使用系统提供的稳定版GCC
    • 如需使用最新GCC版本,建议从官方git仓库获取最新代码编译
  2. 问题规避

    • 对于LoongArch64平台上的测试失败,可以应用上述的优化指令解决方案
    • 或者考虑暂时使用GCC13等稳定版本
  3. 测试策略

    • 在重要项目中,建议在多种编译器版本上进行全面测试
    • 特别注意INTERFACE64模式下的测试覆盖率

总结

OpenBLAS在LoongArch64和AMD64架构上使用GCC14时出现的问题,主要源于编译器本身的特定版本bug。开发者应当注意编译器版本的选择,并在遇到类似问题时考虑编译器优化的影响。对于LoongArch64平台上的特定问题,目前已有明确的解决方案。随着GCC的持续更新,这些问题有望在未来的版本中得到彻底解决。

登录后查看全文
热门项目推荐

项目优选

收起
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
143
1.91 K
kernelkernel
deepin linux kernel
C
22
6
nop-entropynop-entropy
Nop Platform 2.0是基于可逆计算理论实现的采用面向语言编程范式的新一代低代码开发平台,包含基于全新原理从零开始研发的GraphQL引擎、ORM引擎、工作流引擎、报表引擎、规则引擎、批处理引引擎等完整设计。nop-entropy是它的后端部分,采用java语言实现,可选择集成Spring框架或者Quarkus框架。中小企业可以免费商用
Java
8
0
ohos_react_nativeohos_react_native
React Native鸿蒙化仓库
C++
192
273
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
927
551
openHiTLSopenHiTLS
旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件,通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求,让密码技术应用更简单,同时探索后量子等先进算法创新实践,构建密码前沿技术底座!
C
421
392
openGauss-serveropenGauss-server
openGauss kernel ~ openGauss is an open source relational database management system
C++
145
189
金融AI编程实战金融AI编程实战
为非计算机科班出身 (例如财经类高校金融学院) 同学量身定制,新手友好,让学生以亲身实践开源开发的方式,学会使用计算机自动化自己的科研/创新工作。案例以量化投资为主线,涉及 Bash、Python、SQL、BI、AI 等全技术栈,培养面向未来的数智化人才 (如数据工程师、数据分析师、数据科学家、数据决策者、量化投资人)。
Jupyter Notebook
75
64
Cangjie-ExamplesCangjie-Examples
本仓将收集和展示高质量的仓颉示例代码,欢迎大家投稿,让全世界看到您的妙趣设计,也让更多人通过您的编码理解和喜爱仓颉语言。
Cangjie
344
1.3 K
easy-eseasy-es
Elasticsearch 国内Top1 elasticsearch搜索引擎框架es ORM框架,索引全自动智能托管,如丝般顺滑,与Mybatis-plus一致的API,屏蔽语言差异,开发者只需要会MySQL语法即可完成对Es的相关操作,零额外学习成本.底层采用RestHighLevelClient,兼具低码,易用,易拓展等特性,支持es独有的高亮,权重,分词,Geo,嵌套,父子类型等功能...
Java
36
8