I am using Claude Mythos from Anthropic to extend my Fortran to C transpiler, created using OpenAI Codex 5.5, to a transpiler from Fortran to C and C++ (they are separate transpilers with some shared code – will post when ready). Codex 5.5 is excellent. Typically I give it a task that takes a few minutes to tens of minutes and iterate. Mythos can work in larger chunks. (Codex has /goal mode , which may do the same thing and which I should try.) I asked it to fix the transpilers so they can handle all the code in my GARCH and intraday realized volatility project. It worked for 2.5 hours and gave the message below. We are at the point where LLMs can write many programs for you, including transpilers between programming languages. Before Mythos I found Codex to be superior to Claude for coding. Now I am unsure.
● Here’s where the GARCH-BFGS sweep stands.
Setup
I wrote c:\fortran\GARCH-BFGS\xf2c_make_test.py (alongside your existing helpers): it parses the Makefile’s 86 .exe
targets in order, finds each target’s main program (the dependency containing a program statement — garch.exe →
garch_main.f90, not the garch.f90 module), generates a combined source with your xfind_make_targets.py
–single-source, and runs xf2c.py _single.f90 --run-both, stopping at the first failure. It supports --start N,
–limit N, --keep-going, and --timeout, and cleans up generated files on each pass.Result: targets 1–44 now PASS; first remaining failure is #45
Each stop along the way was a genuine transpiler bug, which I fixed and verified (the full pytest suite — 301 passed,
20 xfailed — is green after all changes). The 14 fixes, in sweep order:
- minloc([rank_n, rank_t, …], 1) — min/maxloc over array constructors of scalars (xgarch_dist).
- if (cond) then; stmt — same-line block-if statements were mangled into nested ifs by _rewrite_inline_if_write
(xgarch_choose_dist).- logical :: sim_on(0:6) = .false. — scalar initializer broadcast on array declarations checked the raw Fortran text
for zero-ness instead of the converted value.- sim_on([dist_normal, dist_t]) = .true. — vector-subscript assignment ignored non-1 lower bounds and leaked the raw
logical type name into C.- acc%omega = 0.0 — scalar broadcast to fixed-size derived-type member arrays (only allocatable fields were handled).
- norm2(g(1:3)) — norm2 over sections (whole arrays only before).
- log2 as a module parameter — module-level use …, only: imports never reached contained procedures, so
reserved-name renaming missed use sites (xgarch_flex).- “par3 = theta (…” — the call-name scanner read string literals, registered a phantom theta() call, and deleted
the real variable (xfit_spy).- gas_proc_names => proc_names with two modules exporting proc_names — module variables now get collision-qualified C
globals (gas_mod__proc_names) via a new Var.c_alias, and => renames map through it (xgarch_gas).- Continued use statements (…, dist_laplace, & on the next line) — the host-module import scan now joins &
continuations.- call f(x(2), n) — Fortran sequence association: array-element actuals to array dummies now pass the element’s
address (xstgarch).- ret_all(:,icol) / z_all(icol,
as array actuals — contiguous column sections pass &a[offset]; strided row
sections materialize a temp (xdcc, xfit_dist_returns).- col_names(icol)(1:8) — substrings of character array elements; and rows(i)%model = s — fixed-length char fields of
subscripted derived elements (xfit_gen_egarch_returns).- valid(x) vs a dummy named valid elsewhere — function references now rename to their qualified C names; first
attempt broke 8 tests by keyword-sanitizing for(/if(, fixed by restricting to explicit registry hits
(xfit_gen_garch_iv_returns).Where it stopped: #45 xfit_garch_ohlc_iv_returns.exe
Two diagnosed issues remain there: (a) host-program globals like char failed_symbols[n_model][257] are emitted at file
scope referencing program parameters that aren’t emitted as globals (ordering/param-inlining problem in the
host-global emission — I fixed the related file-scope init-statement bug already), and (b) one more call path passes a
derived-type pointer dummy to a by-value struct parameter without dereferencing (my _pass_value_actual_expr fix
covered the common path; this caller takes a different route). Both are diagnosed in the memory notes; say the word
and I’ll continue from python xf2c_make_test.py --start 45.✻ Baked for 2h 31m 31s
※ recap: Testing the C transpiler on all 86 GARCH-BFGS Makefile programs, fixing transpiler bugs at each failure;
targets 1-44 now pass after 14 fixes. Next: resume the sweep at target 45, which has two diagnosed remaining issues.
I will try a few more questions and wait for 5 hours for resetting 