v1.0.5: bsearch execution stops after function call (inter-TU issue)

[CTalkobt]

Problem

After fixing optimizer regression in #183, emulator testing reveals bsearch still fails with a different root cause. Program execution stops immediately after the bsearch() call.

Reproduction

Test code:

#include <stdlib.h>

volatile unsigned char *test = (unsigned char *)0x4000;

int cmp(const void *a, const void *b) {
    return *(int*)a - *(int*)b;
}

int main() {
    test[0] = 0x11;           // ✓ WRITES CORRECTLY
    int arr[] = {10, 20, 30, 40, 50};
    void *found = bsearch(&arr[2], arr, 5, sizeof(int), cmp);
    test[1] = found ? 0xAA : 0xFF;  // ✗ NEVER EXECUTES
    test[2] = 0xFE;           // ✗ NEVER EXECUTES
    return 0;
}

Emulator result: 11 00 00 at $4000 (only first write executed, program stops)

Analysis

• Optimizer return-value-load regression is FIXED (verified in binary)
• Direct memory writes work correctly
• bsearch call appears to crash/hang or not return properly
• Suggests calling convention mismatch or inter-TU linking corruption

Related Issues

• Bug v1.0.5: Bug: struct tm functions produce wrong results when linked from library #179: struct tm corruption when linked from library (similar symptoms)
• Issue v1.0.5: Restore register keyword ZP optimization after Bug #179 fix #185: register keyword regression (already resolved)

Labels

bugfix, v1.0.5, calling-convention, inter-TU-linking

[CTalkobt]

Related issue: Bug #179 (struct tm corruption when linked from library) exhibits similar inter-TU linking symptoms. Both #179 and #190 likely stem from the same root cause in calling convention or frame allocation handling across linked translation units.

Fixing either bug may resolve the other.

[CTalkobt]

ROOT CAUSE IDENTIFIED

Function Pointer Double Dereference in Code Generation

The compiler generates code that dereferences function pointers TWICE instead of ONCE when making indirect function calls.

Test Case That Confirms

int my_cmp(const void *a, const void *b) {
    test[2] = 0x55;  // Should execute
    return 0;
}

void test_call(int (*f)(const void *a, const void *b)) {
    int a = 1, b = 2;
    int result = f((const void *)&a, (const void *)&b);  // Fails here
}

Result: test[2] is NEVER set to 0x55 - function pointer call fails silently

Generated Assembly (WRONG)

The compiler generates:

ldax.fp __vr0               ; Load function pointer (address of function)
sta __zp_scratch
stx __zp_scratch+1
ldy #0
lda (__zp_scratch),y        ; ERROR: Dereference to get **f
...
stax.fp __vr16              ; Store garbage (**f) instead of address
ldax.fp __vr16
sta @__call_site_0+1        ; Store garbage to call site
jsr $0000                    ; Jump to invalid address

Impact

• ✗ bsearch() doesn't work (needs function pointer)
• ✗ qsort() doesn't work (needs function pointer)
• ✗ ALL callbacks fail (progress callbacks, compare functions, etc.)

Fix Location

Code generator in IRCodeGen.cpp or CodeGenerator.cpp needs to fix function pointer indirect call handling. Should load pointer directly without dereferencing.

This is why inter-TU linking appeared to be the issue - it affects the same functions (bsearch/qsort from library) but the root cause is function pointer code generation.

[CTalkobt]

FIXED in commit ffe0071

Root Cause: IRBuilder.cpp was emitting a LOAD instruction for local function pointer parameters, treating the pointer VALUE as a memory ADDRESS, causing double dereferencing.

The Fix: Removed incorrect LOAD instruction. Function pointer parameters now use their vreg value directly, matching how regular variables work.

Verification:

• ✓ Simple function pointer calls work (test_fp_fix.c)
• ✓ bsearch with function pointer comparator works (test_bsearch_fix.c)
• ✓ qsort with function pointer comparator works (test_qsort_fix.c)
• ✓ Library assembly verified: qsort.o45.s shows correct 3-instruction pattern

Assembly Before Fix (WRONG - 13 instructions):

ldax.fp __vr0
sta __zp_scratch
stx __zp_scratch+1
ldy #0
lda (__zp_scratch),y    ; Double dereference - WRONG!
...

Assembly After Fix (CORRECT - 3 instructions):

ldax.fp __vr0
sta @__call_site+1
stx @__call_site+2
jsr $0000

Impact: All function pointer indirect calls now work (bsearch, qsort, callbacks). This also likely fixes Bug #179 as a side effect.