您好，相关问题我们已经收到了，将在确认后向您反馈~
您好，感谢您的反馈。
针对问题1：最新的CANN 9.1.0分支中include/c_api/vector_datamove/vector_datamove.h中3510版本已增加asc_copy_gm2ub_align(dst, src, size)，请参考：https://gitcode.com/cann/asc-devkit/blob/master/include/c_api/vector_datamove/vector_datamove.h
您好，感谢您的反馈。
针对问题1：最新的CANN 9.1.0分支中include/c_api/vector_datamove/vector_datamove.h中3510版本已增加asc_copy_gm2ub_align(dst, src, size)，请参考：https://gitcode.com/cann/asc-devkit/blob/master/include/c_api/vector_datamove/vector_datamove.h
好的
您好，感谢您的反馈。
针对问题1：最新的CANN 9.1.0分支中include/c_api/vector_datamove/vector_datamove.h中3510版本已增加asc_copy_gm2ub_align(dst, src, size)，请参考：https://gitcode.com/cann/asc-devkit/blob/master/include/c_api/vector_datamove/vector_datamove.h好的
您好，已经解决的问题可以不用在issue中删除，保留即可，也可供其他开发者学习参考~
您好，感谢您的反馈。
关于问题1：
请参考资料AI-Core算子编译基本用法中的内置链接库章节。内置外的库需要用户自行根据需要链接。
关于问题2：
请参考资料核函数中的核函数的调用章节。有如下描述：
核函数（Kernel Function）：运行于设备端（NPU），是Host侧任务下发的执行入口。核函数在组织并行计算逻辑时，可以向下调用其他的Device侧执行函数。
Device侧执行函数：运行于设备端（NPU）的普通函数（除核函数外）。此类函数主要用于封装和复用底层计算逻辑，其调用权限被严格限制在设备侧内部，仅支持被核函数或同类的Device侧执行函数调用。
device函数和核函数仅允许调用device函数。
您好，针对于问题 3：asc_storealign_pack 对 fp16 压缩存储的用法不直观，缺少位宽展开/压缩的完整文档示例
当前C API对于b32转b16后搬出已有相关样例，请参考cast样例的场景2：https://gitcode.com/cann/asc-devkit/tree/master/examples/02_simd_c_api/03_c_api/02_reg_vector_compute/cast
关于C API中该场景的图示，后续将会添加到对应接口的文档中。您当前可参考基础API中已有图示，链接为：https://gitcode.com/cann/asc-devkit/blob/master/docs/zh/api/SIMD-API/basic_api/reg_vector_compute/type_conversion/Cast.md#fig2
你好，在C API的使用上有没有类似于Ascendc的PRINTF或者dumpTensor的可供调试打印的接口呢
问题 1：asc_copy_gm2ub_align 文档与 3510 头文件签名不一致（文档为 3 参数，实际为 10 参数）
现象：asc-devkit 文档（asc_copy_gm2ub_align_arch_3510.md）中展示了 3 参数版 asc_copy_gm2ub_align(dst, src, size)，但 CANN 9.0.0 的 dav-3510 头文件（include/c_api/vector_datamove/vector_datamove.h 3510 段）仅提供 10 参数版，3 参数版只存在于 2201 段。
复现：按文档编写 3 参数调用，在 dav-3510 下编译报错（candidate function not viable: requires 10 arguments）。
期望：文档与工具包头文件保持一致，或补充 3510 架构的接口签名说明。
问题 2：Host 侧使用 std::exp/std::expm1 链接失败：ASC 链接器（cceld）默认不链接系统 libm
现象：Host 侧（kernel 之外）使用标准数学函数计算 golden 时，链接阶段报 undefined symbol: expf/expm1f。
复现：Host 侧使用 std::exp/std::expm1 → cmake .. && make -j 报 undefined symbol → 需手动加 target_link_libraries(... m) 才通过。
期望：链接器默认链接系统 libm，或提供明确文档说明该限制。
问题 3：std::min 在 aicore 设备函数中不可调用，编译报错无匹配函数
现象：aicore 设备函数（如 kernel）中调用 Host 标准库函数 std::min 编译失败，报 no matching function for call to 'min'。
复现：kernel 中写 uint32_t count = std::min(total_length - start, MAX_BLOCK_LENGTH); → 编译报错 → 需改用三元表达式。
期望：文档明确 aicore 中不可调用 Host 标准库函数（std::min/std::max 等）的限制，或提供设备侧等价接口。
问题 4：asc_storealign_pack 对 fp16 压缩存储的用法不直观，缺少位宽展开/压缩的完整文档示例
现象：官方 ops-nn elu kernel（950/arch35）通过 MicroAPI DIST_UNPACK_B16/DIST_PACK_B16 + Cast 将 fp16 展开到 fp32 域计算后再转回。C API 层有完全等价能力（asc_loadalign_unpack + asc_half2float + asc_float2half_rn + asc_storealign_pack），但 asc_storealign_pack 对 fp16 压缩需以 int32 视图调用（(vector_int32_t)dst_half + (int32_t*)dst + n/2，对应 PK_B32），直接用 half 版本会因掩码语义不同产生交错错位（实测 matched_ratio=0.25）。
复现：1) 用 asc_loadalign_unpack + asc_half2float 展开到 fp32 域计算，asc_float2half_rn 写回偶数位；2) 直接用 half 版本 asc_storealign_pack((ubuf half*)dst, dst_half, mask) 存储，实测 matched_ratio=0.25；3) 改 int32 视图后正确（matched_ratio=1）。
期望：在 C API 文档中补充 fp16 位宽展开（加载）/压缩（存储）的完整示例，说明需以 int32 视图调用。
总结： 以上 4 项均属于文档/工具链在开发中暴露出的易用性问题，按文档或常规写法无法直接完成开发，需开发者自行踩坑适配。建议分别补充文档说明、统一接口签名或增加示例，降低后续开发者的使用成本。其中问题 1 已获官方回应确认：CANN 9.1.0 已在 3510 段补充 3 参数版 asc_copy_gm2ub_align，文档/头文件一致性已修复。