SSA sanity check fails on nested shift with untyped constant: `value << (1 << byteVar)`

[cpunion]

Description

When compiling code containing a nested shift expression where the inner shift has an untyped constant as the left operand and a byte variable as the right operand, the SSA sanity check fails with:

Error: function xxx, block 0: instruction has 'untyped' result: t2 = 1:untyped int << t1 : untyped int
Error: function xxx, block 0: operand #0 of convert uint <- untyped int (t2) is untyped: untyped int
panic: SanityCheck failed

Reproduction

The following code triggers the bug:

func nestedShift(bytes []byte) uint32 {
    value := uint32(1)
    return value << (1 << bytes[3])  // BUG: inner shift produces untyped int
}

This pattern is used in real-world code, e.g., github.com/marcinbor85/gohex:

adr = uint32(binary.BigEndian.Uint16(bytes[4:6])) << (1 << bytes[3])

SSA Output

The SSA for the nested shift shows the problem:

t1 = *t0                                           byte
t2 = 1:untyped int << t1                    untyped int  ← BUG
t3 = convert uint <- untyped int (t2)              uint
t4 = 1:uint32 << t3                              uint32

The expression 1 << t1 produces untyped int instead of being properly typed.

Key Observation

• uint(1 << bytes[3]) - ✅ Works (simple shift with explicit conversion)
• value << (1 << bytes[3]) - ❌ Fails (nested shift, inner expression untyped)

The bug is triggered when an untyped shift expression is used as the right operand of another shift expression.

Environment

• Go version: 1.24.x
• golang.org/x/tools: v0.36.0

[cpunion]

Investigation Complete

We have confirmed this is a known issue with go/types type checker.

Root Cause

For non-constant shift expressions like 1 << bytes[3], go/types returns untyped int as the expression type in TypeAndValue. However, according to the Go spec:

"If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone."

This means it should return int (the default type), not untyped int.

When go/ssa (from x/tools) is used with SanityCheckFunctions mode, it validates that no instruction results have untyped types, causing the panic.

Reported Upstream

This issue has been reported to golang/go: golang/go#77067

Workaround

We have implemented a workaround in llgo that fixes the TypesInfo before calling prog.CreatePackage:

func fixUntypedShiftTypes(p *packages.Package) {
    for expr, tv := range p.TypesInfo.Types {
        if binExpr, ok := expr.(*ast.BinaryExpr); ok {
            if binExpr.Op == token.SHL || binExpr.Op == token.SHR {
                if basic, ok := tv.Type.(*types.Basic); ok {
                    if basic.Info()&types.IsUntyped != 0 {
                        p.TypesInfo.Types[expr] = types.TypeAndValue{
                            Type:  types.Default(tv.Type),
                            Value: tv.Value,
                        }
                    }
                }
            }
        }
    }
}

A PR with this fix and test cases will follow shortly.