一、问题描述

MulNoNan的InferShape没有独立校验rank上限，对rank9输入返回成功；InferDataType只要求两个输入类型相同，BOOL/BOOL、DOUBLE/DOUBLE、COMPLEX128/COMPLEX128均被原样放行。

测试参考还存在两个问题：用NumPy承担最终dtype舍入；TF TestSpec回落到原生CPU TF golden时，合法的六维广播在参考生成阶段失败。GE示例固定设备0，无法通过参数选择资源泳道。

二、环境信息

• Ascend950PR_9579，CANN Toolkit 9.3.0，算子包由ops-math主线f94a6cd6df2393c2621bf574089f8f51b4bc61b3构建。
• TTK fb6f02fcfa67bcd25c942875bad9f3023700f4ba，Python 3.12.9；TF参考问题在TensorFlow 2.21 CPU也可复现。
• TTK单进程，构建并行度4；数值比较使用高精度CPU参考及真实A100/Torch参考。

三、重现步骤

1. 用SDK上下文构造器调用包内实际注册的InferShape：x1=[1,1,1,1,1,1,1,1,1]、x2=[1]，旧回调返回成功。把rank9放在另一输入，或令另一输入未知rank，现象相同。
2. 调用InferDataType，传入BOOL/BOOL等同类型的非法输入，旧回调返回成功。
3. CPU上调用TF MulNoNan，输入shape分别为(2,3,2,2,2,2)、(1,3,1,2,1,2)，总输出仅96个元素，仍报“Broadcast between ... is not supported yet”。错误发生在参考生成，不是NPU执行。

四、预期结果

已知非法rank和dtype在对应Host推导阶段拒绝，合法标量、广播、动态shape/rank及GE空Tensor保持正常。数学参考覆盖合法输入域并保留提升精度，GE示例允许选择设备。

日志与验证

主线包直接Host探针确认6条非法输入被放行。改后17条Host检查符合预期；19条Kernel小用例三种编译路径通过，GE 31/31通过。TF参考缺陷用缩小用例复现后，修正的TTK golden生成子路径已核对输出；这不代表新增TensorFlow NPU用户入口。

直接Kernel的0D在线编译错误已定位到CANN代码生成的reduce()，不属于本次算子仓修改，GE/release标量路径已通过。

备注

质量看板：https://cann.cannbot.cn/harnessmcp-tests/evaluation/validation/upload-20261025132522-mulnonan-dcdb0814?tab=testcases

关联PR：https://gitcode.com/cann/ops-math/merge_requests/6971

当前修复已完整cherry-pick到PR !6947，统一随AddV2/TensorRedirect修复评审合入；关联总问题为Issue #4378。原PR !6971及源提交6f1e0471275f6f1f7d08232dd823636b4a1a5279保留用于追溯。

组合提交af1eeea72c5c773ed3fb136d9ea75d3228b9d90d，基于官方master 58e411acd306ae5d391301bf2e21d25d1bf4fae5，仅1提交。引入的MulNoNan 8文件与源提交逐字节一致。本轮A5指定入口CI通过，组合Host UT151、Graph UT6、CPU Kernel UT2；MulNoNan仓内8条binary/static/GEIR数值执行均通过。CLI CPU golden binary_equal不表示本地GPU cross_check已验证；原产品支持和源PR历史验证范围不变。

已向同一受测SHA提交compile触发线上CI；线上流水线已启动，结果待出，不由本地通过推断。