您好,感谢反馈!
问题分析
报告中的两条失败来自同一项检查:lin_space_tiling_int64_big_num 和 lin_space_tiling_int64_num 都把 tinfo.tilingDataSize 固定断言为 128,而本次日志记录的实际值是 168。
核查提交 212ce9d5460b1be26cfbee481aff1acbf5cc5c62 的 LinSpace UT,这两处固定值确实存在;公共执行器 则从 GetRawTilingData()->GetDataSize() 取实际长度并复制数据。源码支持“用例固定长度与当前运行返回长度不一致”的判断;168 字节的具体布局还需结合报告对应的 opbase 版本确认。
处理方向
可行方向是按实际 tiling 数据接口核对有效载荷、布局及解码方式,调整固定长度假设,同时保留 INT64 的 16777219 和 17 计数、tilingKey、blockNum 与 workspace 校验。尤其不能只把 128 改成 168 就认定完成:若布局发生变化,p[2] 是否仍对应 num 也需一起确认。
这两例承担大整数计数不经 FLOAT 丢精度的回归检查,修订应保留这一目的。当前已有负责人,继续由现有负责人跟踪该 UT 兼容问题。


问题描述
lin_space_tiling_int64_big_num / lin_space_tiling_int64_num 在 test_lin_space_tiling.cpp:68/:94 硬编码 ASSERT_EQ(tinfo.tilingDataSize, 128),实际为 168(168 vs 128)。tilingDataSize 除 TilingData 外还包含框架头/对齐开销,固定 128 不成立。
修改建议
- 去掉对绝对
tilingDataSize的硬编码断言,改为按sizeof(LinSpaceTilingData)或框架实际开销计算期望值(当前为 168); - 或只校验必要的 tiling 字段,避免依赖易变的框架内部布局。
以上为 UT 每日扫描基于本次失败日志的初步定位,供修复参考。


您好,补充扫描中的 128/168 长度不一致与前次定位一致。这里需要区分算子有效载荷大小和框架返回的 raw tiling data 长度:单独用 sizeof(LinSpaceTilingData) 替换断言,仍需先确认头部、对齐和实际解码位置。
一个更稳妥的方向是保留 tilingKey、blockNum、workspace 及 INT64 大整数计数等语义检查,按当前序列化接口解码所需字段,避免把框架内部总长度固定为 128 或 168。现有负责人继续跟踪这两例;目前尚无对应修订通过验证的结论。


缺陷描述
仓名: cann/ops-math
算子名: math/lin_space
失败用例数: 2
用例汇总
用例详情
1. LinSpaceTiling.lin_space_tiling_int64_big_num
复现命令:
2. LinSpaceTiling.lin_space_tiling_int64_num
复现命令: