Iteration counter displays 0 on musl-compiled binaries (display-only, math correct)

[ehrlinger]

Summary

On musl-compiled builds (e.g. CCF RHEL 8 native build), the optimizer iteration counter in the listing output always displays 0 for every row, and the termination message reads "Optimization terminated after 0 iterations" regardless of the actual number of iterations. Numerical results are unaffected — only the display is wrong.

Observed behavior

Iteration trace table (musl build):

Iteration   Log Likelihood   E2   E3   ...
-----------------------------------------------------------------
    0        -322.226        ...
    0        -322.226        ...
    0        -322.226        ...

Termination line:

Optimization terminated after 0 iterations and 77 function evaluations

Expected behavior (glibc dynamic build, v4.3.0 reference)

Iteration   Log Likelihood   E2   E3   ...
-----------------------------------------------------------------
    0        ...
    1        ...
    2        ...
    ...
    5        -322.226        ...

Termination line:

Optimization terminated after 5 iterations and 77 function evaluations

Affected platforms

• CCF production server (lri-sas-p-02, RHEL 8, native musl gcc build)
• Any system where the binary is compiled against musl libc
• Not affected: glibc dynamic builds (CI Ubuntu runners, macOS)

Pre-existing

Confirmed present in v4.4.5 build on the same server — this is not a v4.4.6 regression.

Diagnostic plan

1. Add fprintf(stderr, "DEBUG: itrcnt=%d at %p\n", O->itrcnt, &O->itrcnt) in OPTPRTX() (src/hazard/hazrd3.c) and at the itrcnt++ site in setoptim.c.
2. If addresses differ → struct padding mismatch between musl and glibc. The #ifdef STRUCT global allocation in one TU and extern declarations in all others means a layout difference puts itrcnt at different byte offsets.
3. Check with offsetof(typeof(*O), itrcnt) in both environments.

Likely fix

Explicit padding or alignment on the field(s) before itrcnt in structures.h, or re-ordering struct members to eliminate the padding difference. Alternatively, a missing volatile or compiler-inlining issue in a loop context.

Notes

• Math output is correct on musl builds — only the display counter is wrong
• Static glibc builds (LDFLAGS=-static) were investigated as a workaround but produce incorrect numerical results due to libm ifunc resolver differences; not a viable deployment path
• Target: v4.4.7 (bug-fix, pre-existing, display-only)