CLA协议签署
当前Pull Request的提交暂无外部代码贡献者合并受阻
PR创建成功通知 | 感谢您的贡献 🎉
您好！系统已检测到您成功创建 Pull Request（PR），感谢您对项目的支持与参与！以下几点需要您着重关注：
一、PR必须关联Issue ❗️
触发门禁检查的必要步骤：在PR描述框输入Issue完整链接，完成Issue关联。
请注意，一个 Issue 不能同时关联同一 base 仓库内同一个分支的多个开启状态的 PR
二、门禁触发规则 🔧
- 门禁类型判定：由Issue关联的PR所属代码仓数量决定
- 关联多个代码仓PR：触发「多仓联合门禁」
- 关联单个代码仓PR：触发「单仓门禁」
- 启动指令与检查范围：需主动回复指令：
- 回复 "start build"：执行Cangjie的主要基础检查，包含commit格式检查、静态告警分析、OAT开源声明检查、多平台构建、单元/集成测试等
- 关联同一issue的多个PR，仅需在任意一个PR里回复触发一次门禁，该PR门禁通过后，所有PR都会添加Label和测试人
- 每个pr只能同时运行一条CI流水线，如需重新启动，请先关闭运行中的，再评论触发门禁
- Markdown修改仅触发文档类构建测试门禁，不会触发Cangjie的编译测试门禁
- commit 信息格式请遵循：Conventional Commits 规范
- 请保证每一条 commit 都已添加
Signed-Off-By信息 - 回复 "start build cov"：执行覆盖率构建工程，生成该提交的增量代码覆盖率报告
三、合入条件 ⚠️
- 满足最低评审人数，且评审问题需全部解决；
- 禁止合入本人创建的PR，需由其他协作者操作；
- 合并前确保关联流水线任务运行成功（build-test-passed）；
- 需求类覆盖率门禁：当关联的 Issue 标题以
[feature]:开头（需求类 Issue）时，联合提交中属于cangjie_compiler、cangjie_runtime、cangjie_stdx、cangjie_tools、llvm-project仓库的 PR，必须先回复 "start build cov" 触发增量覆盖率流水线并通过，使 PR 获得cov-test-passed标签后方可合入。
四、合并PR ✅
回复 "start merge"，CI流水线会自动检查所有关联PR的状态、版本号标签、检视意见密度、兼容性、需求类覆盖率门禁，若所有PR都满足合并条件，则将会同时合并所有PR。若存在不满足合并条件的PR，则不会合并任何PR。
如果希望不进行兼容性相关的检测，请任一合法审查人复制以下内容，在 start merge 前提交评论：
本 pr 不需要兼容性相关检测，对于引发的任何兼容性问题（即由于本 pr 合入将导致用户需适配代码的话），由本人承担。
If you wish to avoid compatibility-related checks, please have any approver copy the following content and submit it as a comment before sending start merge:
This PR does not require compatibility-related checks. For any compatibility issues caused by this PR (i.e., if the integration of this PR will require users to adapt their code), I will take full responsibility.
五、补充说明 📢
- 详细仓颉贡献流程：贡献流程(Cangjie Community Contribution)
- 门禁结果将自动评论至关联的所有PR，敬请留意。
⚠️ 检测到Cangjie/llvm-project#607代码变化，请回复'start build'重新运行门禁
⚠️ Code changes detected in Cangjie/llvm-project#607, please reply 'start build' to rerun the gate
⚠️ 检测到Cangjie/cangjie_test#2050代码变化，请回复'start build'重新运行门禁
⚠️ Code changes detected in Cangjie/cangjie_test#2050, please reply 'start build' to rerun the gate
llvm-project仓PR信息
变更内容**（必填）**
修复 issue https://gitcode.com/Cangjie/cangjie_compiler/issues/1089 的问题一：finalizer 对象的字段读被 LICM 提升出循环，导致 GC 活性分析判定该对象在循环内已死，GC 中途回收对象并提前执行
~init()。变更点：
llvm/lib/Transforms/Scalar/LICM.cpp：在canSinkOrHoistInst的LoadInst分支新增 finalizer 对象保护——当CJPipeline && maybeCJFinalizerObj(LI->getPointerOperand())时禁止对该 load 做循环提升/下沉，复用 GVN 中已有的maybeCJFinalizerObj判定。llvm/test/Transforms/Cangjie/LICM/licm_finalizer_field.ll：新增回归用例，验证 finalizer 对象的字段读在--cangjie-pipeline下必须留在循环体内（hoist/sink 都会使 GC 活性分析误判对象已死）。变更类型**（必填）**
变更内容自检
编译器及标准库编译通过截图证明（如涉及新增需求、问题修复、构建过程变动需提供）
本地完整编译
llvm-project通过：增量构建cjnative并 install 到output/third_party/llvm，opt产物可正常运行带--cangjie-pipeline的管线。测试用例本地自验证通过截图证明（如涉及新增需求、问题修复需提供）
llvm/test/Transforms/Cangjie/LICM/licm_finalizer_field.ll：opt < %s -licm --cangjie-pipeline -S | FileCheck %sPASS（load 保留在循环体内）。--cangjie-pipeline）时同一用例 FAIL（load 被提升到 entry），证明用例对修复回退敏感。cjc cangjie_compiler/IR/test1.cj -O2 --save-temps编译通过，运行./main1,000,000 次迭代全部完成、退出码 0，不再抛出NoneValueException。其他信息
关联 issue：https://gitcode.com/Cangjie/cangjie_compiler/issues/1089
本修复为纯保守改动：仅在 Cangjie 管线（
CJPipeline）下生效，普通 LLVM 的opt -licm行为不变。变更文件
llvm/lib/Transforms/Scalar/LICM.cppllvm/test/Transforms/Cangjie/LICM/licm_finalizer_field.ll