现象

aclnnReplicationPad1d 传入负 padding（裁剪语义）时，A2 上图 2 的两段式接口都返回 0，但 aclrtSynchronizeStream 返回 507035（AICore vector core exception）；同一份代码的正 padding 正常，INT32 输入的负 padding 也正常。

同一台机器逐项对照（FLOAT32，self=[2,6]，ASCEND_LAUNCH_BLOCKING=1）：

同族接口在同一台机器上现象一致：aclnnReplicationPad2d（FLOAT32 [1,2,4,6]、-1,-1,-1,-1）与 aclnnReplicationPad3d（FLOAT32 [1,2,3,4,6]、六向 -1）同样 sync=507035。复现频率 2/2（连续两轮、两个 dtype、三个接口全部命中；正 padding 到 8000 不触发，与偏移量级无关）。

期望

资料 docs/aclnnReplicationPad1d.md 的参数表「padding 使用说明」只写了「长度为 2，两个数值依次代表左右两边需要填充的值」，没有限制符号；op_api 的 SafePadSum()（conversion/pad_v3/op_api/op_replication_pad.h:51-68）明确实现了负值裁剪语义：padFront < 0 && dimSize + padFront < 0 才判非法，否则按 dimSize + padFront + padBack 计算输出维。

所以负 padding 是 host 侧主动放行的合法入参，预期行为是二者之一：

• 按裁剪语义算出与 torch.nn.functional.pad(x, (-1,-1), mode='replicate') 一致的 [2,4]（INT32 现在就是这样）；
• 或者在 host 侧以 161002 明确拒绝。

不应出现「两段都返回 0、device 侧抛 vector core exception」。

环境

复现步骤

1. 把下方「复现脚本」存为 repro_replpad_neg.cpp
2. 编译：g++ -std=c++17 -O2 repro_replpad_neg.cpp -o repro -I$ASCEND_HOME_PATH/include -L$ASCEND_HOME_PATH/lib64 -lascendcl -lopapi -lnnopbase
3. 运行：ASCEND_LAUNCH_BLOCKING=1 ./repro
4. 看 positive-pad 一行：三个返回码都是 0
5. 看 negative-pad 一行：sync=507035

复现脚本

// aclnnReplicationPad1d 负 padding（裁剪）最小复现
#include <cstdio>
#include <vector>
#include "acl/acl.h"
#include "aclnnop/aclnn_replication_pad1d.h"

static aclTensor* MakeTensor(std::vector<float>& host, std::vector<int64_t>& shape, void** devPtr) {
    int64_t n = 1;
    for (auto d : shape) n *= d;
    size_t bytes = size_t(n) * sizeof(float);
    aclrtMalloc(devPtr, bytes, ACL_MEM_MALLOC_HUGE_FIRST);
    aclrtMemcpy(*devPtr, bytes, host.data(), bytes, ACL_MEMCPY_HOST_TO_DEVICE);
    std::vector<int64_t> strides(shape.size(), 1);
    for (int64_t i = int64_t(shape.size()) - 2; i >= 0; --i) strides[i] = shape[i + 1] * strides[i + 1];
    return aclCreateTensor(shape.data(), shape.size(), ACL_FLOAT, strides.data(), 0,
                           ACL_FORMAT_ND, shape.data(), shape.size(), *devPtr);
}

static void RunCase(const char* tag, std::vector<int64_t> inShape, std::vector<int64_t> outShape,
                    std::vector<int64_t> pads, aclrtStream stream) {
    int64_t nIn = 1, nOut = 1;
    for (auto d : inShape) nIn *= d;
    for (auto d : outShape) nOut *= d;
    std::vector<float> selfHost(size_t(nIn)), outHost(size_t(nOut), -7.0f);
    for (int64_t i = 0; i < nIn; ++i) selfHost[size_t(i)] = float(i + 1);
    void *selfDev = nullptr, *outDev = nullptr;
    aclTensor* self = MakeTensor(selfHost, inShape, &selfDev);
    aclTensor* out = MakeTensor(outHost, outShape, &outDev);
    aclIntArray* padArr = aclCreateIntArray(pads.data(), int64_t(pads.size()));
    uint64_t wsSize = 0;
    aclOpExecutor* executor = nullptr;
    auto rc1 = aclnnReplicationPad1dGetWorkspaceSize(self, padArr, out, &wsSize, &executor);
    void* ws = nullptr;
    if (wsSize > 0) aclrtMalloc(&ws, wsSize, ACL_MEM_MALLOC_HUGE_FIRST);
    auto rc2 = aclnnReplicationPad1d(ws, wsSize, executor, stream);
    auto rc3 = (rc1 == 0 && rc2 == 0) ? aclrtSynchronizeStream(stream) : -1;
    printf("[%s] gws=%d exec=%d sync=%d\n", tag, int(rc1), int(rc2), int(rc3));
    aclDestroyTensor(self); aclDestroyTensor(out); aclDestroyIntArray(padArr);
    if (ws) aclrtFree(ws);
    aclrtFree(selfDev); aclrtFree(outDev);
}

int main() {
    aclInit(nullptr);
    aclrtSetDevice(0);
    aclrtStream stream = nullptr;
    aclrtCreateStream(&stream);
    RunCase("positive-pad", {2, 6}, {2, 8}, {1, 1}, stream);    // 阳性对照
    RunCase("negative-pad", {2, 6}, {2, 4}, {-1, -1}, stream);  // 缺陷路径
    aclrtDestroyStream(stream);
    aclrtResetDevice(0);
    aclFinalize();
    return 0;
}

实测输出（A2 + CANN 9.2.0，连续两次一致）：

[positive-pad] gws=0 exec=0 sync=0
[negative-pad] gws=0 exec=0 sync=507035

影响

调用方按裁剪语义传负 padding（crop-then-pad、模型里的对齐裁剪）时会拿到「内核异常」而不是参数错误，且同一份代码在 INT32 上正常、只在浮点上失败，混合精度流程里容易被误判成偶发；当前只能靠外部预先判断 padding 符号绕过。

建议

• conversion/pad_v3/op_api/op_replication_pad.h:51-68 的 SafePadSum() 既然放行负值，kernel 侧就应有对应的裁剪分支，或 host 侧统一改判 161002；建议按前者对齐 torch 语义（INT32 已经正确，可作为参照实现）。
• conversion/pad_v3/tests/st/aclnnReplicationPad1d|2d|3d 目前没有负 padding 用例，建议各补一条（padding=-1,-1、padding=-2,1，fp32/fp16/int32 三档）。
• 同族历史问题可参考 #2161（aclnnReplicationPad1dBackward 在 padding 过大时 507035）：本次是前向接口在负 padding 下的同类设备侧异常，建议一并检查 index/loop 边界。