From f66f9f261a0d62b93fbde086b416850cb951dd75 Mon Sep 17 00:00:00 2001
From: ringabout <43030857+ringabout@users.noreply.github.com>
Date: Thu, 9 Oct 2025 01:10:09 +0800
Subject: [PATCH] fixes #25204; Uninitialized variable usage in
 resize__system_u... in @psystem.nim.c in ORC (#25209)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

fixes #25204

```nim
  of mUnaryMinusI..mAbsI: unaryArithOverflow(p, e, d, op)
  of mAddI..mPred: binaryArithOverflow(p, e, d, op)
```
Arithmetic operations may raise exceptions. So we cannot entrust the
optimizer to skip `result` initialization in this situation, as
complained righteously by `gcc` and `clang`: `warning: ‘result’ may be
used uninitialized [-Wmaybe-uninitialize]`.

With this PR, `clang -c -Wuninitialized -O1 @psystem.nim.c` no longer
gives warnings

(cherry picked from commit 7c65d9e74704b2767520c6bc77ed315deab85cd9)
---
 compiler/cgen.nim | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/compiler/cgen.nim b/compiler/cgen.nim
index 9de707d5c6..68cefe0fae 100644
--- a/compiler/cgen.nim
+++ b/compiler/cgen.nim
@@ -1154,6 +1154,11 @@ proc allPathsAsgnResult(p: BProc; n: PNode): InitResultEnum =
         (n[0].kind == nkSym and sfNoReturn in n[0].sym.flags):
       # requires initializations when encountering unreachable code
       result = InitRequired
+    elif n[0].kind == nkSym and
+        n[0].sym.magic in {mUnaryMinusI..mAbsI, mAddI..mPred} and
+          optOverflowCheck in p.config.options:
+      # arithmetic operations may raise exceptions
+      result = InitRequired
     else:
       for i in 0..<n.safeLen:
         allPathsInBranch(n[i])