Repository navigation
Claude/upgrade ape c library mm z gd - #629
Merged
Merged
Conversation
`initzero-test' under pcc reports 0 where it reported 6, and every section passes. THE SIX THAT MOVED ARE EXACTLY THE SIX THAT FAILED -- 1a, 2b, 3a, 4a, 6a and 7 -- while 1b, 2a and 6b, which had passed by luck against a slot that happened to hold zero, still pass. AND 1c, 3b AND 4b ARE WHAT MAKE IT A CORRECT FIX RATHER THAN A BLANKET ONE. They assert that the NAMED members survive, so a clitzero() that zeroed more than the gaps -- or that ran AFTER the member stores instead of before, which is the ordering the whole design rests on -- would have broken them. They did not move. That run is also the first build of every pending cc/ change, sualign()'s six lines included: the compiler compiles and produces a working compiler. That is the weakest useful result for a front-end change and is the precondition for the rest of the recorded order -- structalign-test's three runs, the acid after-dump, the distclean, and cpfe. Not yet said: whether muon RUNS. Its binary was built by the old compiler, so the fix reaches it only after a rebuild. A test passing and the program working are two claims, and the second is the one this started from. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs
…from Rebuilt with the fixed compiler, muon reaches its own dispatcher and prints its own usage -- `muon' alone answers `error missing command', `muon -h' lists its ten subcommands. No `fault write addr=0x7ffffff000' anywhere: the memset that walked off the top of the stack is gone, because `tstr_init''s `.len' is now the zero C always said it was. THE CHAIN IS MEASURED END TO END RATHER THAN ARGUED. lstk() named the member; initzero-test reproduced it from the suspected cause and its control fired; cc/dcl.c explained why only compound literals had it, since `adlist' has always called contig() and `compoundlit()' never did; and the program that crashed now runs. TWO THINGS IN THAT OUTPUT ARE NOT OURS, and saying so is the point. `muon --help' answering `illegal option -- -' is POSIX getopt doing exactly the right thing: muon has no long options -- its own usage lists `-h' -- and `--help' is not the bare `--' that ends an option list, so it parses as the option character `-'. glibc prints the same. And the `[31m'/`[0m' printed literally is rio, which speaks no escape sequences; under vts it renders, which is one of the three things vts was for. AND TWO CLAIMS IN CLAUDE.md WERE STALE, corrected by reading the mkfile rather than the note: `muon' and `basic' are both LIVE in _OPTIONAL_APPS, where this file said each was commented out. Only `edg' and `c++lib' remain off. The caution that paragraph recorded is unchanged and kept: one failing entry aborts the whole tree's mk, so anything newly enabled is something the next full rebuild can stop on, and a port built only by hand has not been measured in that position. What is NOT measured is muon doing any work. Printing a usage exercises argument handling and one tstr; `muon setup' on a real meson.build is the next thing that would say anything. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs
mk clean and mk distclean both hung IN CLISP, so the tree that was then built was a mixture of objects from before and after a layout change. That is one fact about the other two stops and it has to be ruled out before anything else is blamed. clisp: two bugs. mkfile.rebuild answered `token '=': syntax error' again -- and the only `=' characters left in that recipe were the two inside the COMMENT that explained the previous fix. mk hands a recipe to rc verbatim, so every tab-indented `#' line is rc source. Which construct rc actually refuses is NOT settled -- there is no rc on the build host and the tree has working precedents for a plain recipe comment and for `#' inside a quoted argument -- so sys/lib/tests/mkrecipe-probe is one `mk -k' run that names it, and both clisp mkfiles now carry no comments inside any recipe at all. And the hang is its own bug: clean/nuke drove GNU make over a 300-Makefile autoconf build, which can reconfigure and prompt, and mk propagates a failing clean up through every enclosing directory, so one hung package took the whole tree's clean with it. Both are rm -rf of the build directory now, which is build output in full. go: CC=pcc with no -c, so the driver compiled AND LINKED arm.c and answered `_apemain: undefined: main in _apemain' -- a link error about the second half of a command whose first half worked. Every other APE package says `CC=pcc -c'. Reached only because the `bool' fix let the build get past the first file. perl: OPEN. miniperl links and then faults generating perlmain.c, `fault write addr=0x3000000f0' -- high half 3, low half 0xf0, the shape of an eight-byte slot assembled from two four-byte ones. Either the half-cleaned tree or the sualign bit-field change, and perl's struct op is exactly the shape that moves: eight PERL_BITFIELD16 fields then `U8 op_flags; U8 op_private;'. A complete distclean separates them. bfmove-sweep did not report perl and the reason is the sweep's: its `sharer' regex matches a type NAME, so a package spelling its small types as typedefs is invisible to it -- the pointer false positive of one round earlier, from the other side. It now has an UNKNOWN column (978 under external/) reported rather than counted. go, clisp and perl are commented out of _OPTIONAL_APPS under the rule edg already records: one failing entry aborts the whole tree's mk, so build them by hand first. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.