Misc. bug: auto_fgdn hardcoded false so the fused GDN probe never runs

快速结论：当 src/llama-context.cpp 中的 cparams.auto_fgdn 被固定为 false 时，fused GDN（门控 delta net）探测分支永远不会执行，导致 fused_gdn_ch 保持 true、build_delta_net_chunking 不被调用，ggml_solve_tri 因此在真实模型推理中不可达。优先确认该标志是否为有意关闭，再决定改为 true 还是删除死分支。

适用环境：Issue 已确认：llama.cpp 0.9.0-dev（build 12182，commit d1458d993，基于上游 ca89968a2 的本地分支）、Linux x86_64、GNU 15.2.0 编译、HIP 构建（build-hip）；涉及模块为 libllama；复现模型为 Qwen3.5-0.8B.q8_0.gguf。另有评论者在 Metal/macOS 上验证候选修复。Issue 未给出 Python、CUDA、PyTorch 或具体显卡型号。

最快修复方案：暂无确认的一步修复方案（Issue 讨论未合入正式修复）。可优先尝试将 src/llama-context.cpp 中 auto_fgdn = false 改为 auto_fgdn = true，然后重新编译并跑 test-backend-ops test -j 1 -o SOLVE_TRI 验证。

注意事项：讨论中存在两种候选修复：把标志设为 true，或连带删除探测分支与标志。选哪种取决于该探测是否被有意在某后端禁用，Issue 未给出定论。评论者的验证结果是 Metal/macOS 上 24/24 通过，HIP/Linux 路径未在讨论中确认；在其他后端启用 fused GDN 前，建议单独跑一遍 SOLVE_TRI 与 delta net 相关算子测试。

问题场景

用户在 Linux x86_64 上使用 HIP 构建的 llama.cpp 运行 llama-cli 加载 Qwen3.5 系列 GGUF 模型（Qwen3.5-0.8B.q8_0.gguf，参数 -ngl 99），同时使用 test-backend-ops test -j 1 -o SOLVE_TRI 做对照测试。实际推理日志只打印 “Flash Attention enabled” 和 DeepSeek V4 HC 相关的解析行，没有 GDN 解析行；对 ggml_cuda_op_solve_tri 插桩后，真实模型运行时为 0 次调用，而 test-backend-ops 中有 24 次调用（正控制）。

报错原文

Misc. bug: auto_fgdn hardcoded false so the fused GDN probe never runs

resolve_fused_ops: Flash Attention enabled
resolve_fused_ops: resolving fused DeepSeek V4 HC support:
resolve_fused_ops: fused DeepSeek V4 HC pre enabled
resolve_fused_ops: fused DeepSeek V4 HC comb enabled
resolve_fused_ops: fused DeepSeek V4 HC post enabled

以上日志中没有出现 GDN resolution 行，即为本问题的表现。

原因分析

据 Issue：“At src/llama-context.cpp:327, cparams.auto_fgdn = false;. It is never assigned true anywhere in the tree.”该标志仅在后续行被读取并再次清除，因此 resolve(llm_fused_op_gdn_ar_probe, ...) 与 gdn_ch_probe 所在的代码块不会执行。与相邻的 auto_fhc、auto_fa 对比可见，后两者要么硬编码为 true，要么由用户参数推导，唯独 auto_fgdn 被硬编码为 false。

其后果是 fused_gdn_ch 保持 true，build_delta_net_chunking 不会运行，而 ggml_solve_tri 的唯一调用点位于该函数内，因此从任何模型路径都无法触达。讨论中评论者也定位到 src/llama-context.cpp 中相同位置的行号（其代码版本为第 352、727 行）。

可能原因：该探测被有意关闭，或属于遗漏的默认值。Issue 中未能确认，需由维护者判断。

环境排查

确认 llama.cpp 提交号，Issue 环境为 d1458d993（基于 ca89968a2）。
确认构建后端：HIP 与 CUDA 构建会走 ggml_cuda_op_solve_tri，其他后端行为需单独验证。
确认模型类型：只有 GDN/delta net 类模型（如 qwen35）才涉及 build_delta_net_chunking 路径。
确认 src/llama-context.cpp 中 auto_fgdn 的当前取值及是否被其他位置赋值为 true。
确认对照测试命令 test-backend-ops test -j 1 -o SOLVE_TRI 是否仍能正常通过。

解决步骤

在 src/llama-context.cpp 中定位 cparams.auto_fgdn = false;，并全局搜索 auto_fgdn，确认除该赋值外没有其他赋 true 的位置。
按评论者的候选修复，将 auto_fgdn 改为 true，使其与 auto_fhc 的处理方式一致，从而让 GDN 探测分支得以执行。
重新编译（HIP 构建可继续使用 build-hip）。
对 ggml_cuda_op_solve_tri 插桩，或在启用探测后观察 resolve_fused_ops 是否输出 GDN resolution 行。
运行 test-backend-ops test -j 1 -o SOLVE_TRI，确认算子测试仍通过。
若维护者确认该探测本就是有意禁用，则改为删除探测分支及 auto_fgdn 标志，避免保留不可达代码；两种方案在讨论中均被列为候选。

验证方法

用 llama-cli 运行 qwen35 模型，日志中应出现 GDN 解析行，而非仅有 Flash Attention 与 DeepSeek V4 HC 行；对 ggml_cuda_op_solve_tri 插桩后，真实模型运行时应出现大于 0 的调用次数。同时 test-backend-ops test -j 1 -o SOLVE_TRI 应保持 24/24 通过（该数字为 Issue 中报告的对照结果）。