The bug probably wasn’t reproducing on Linux because the clang shipped with Xcode is from Apple’s fork. The version may say “15”, but it was closer to upstream LLVM’s clang 16. There are also changes that haven’t been upstreamed yet and probably some that may not ever be (if my experience updating libtapi in nixpkgs was anything to go by).
i tried reproducing the zipped example on macOS 14.4.1 (23E224) and Apple clang version 15.0.0 (clang-1500.3.9.4) and it looks like the issue is not present on that version.
here are the instructions marked with '<<<<' from `disassem.txt` and my version:
on my version it uses the offset for the first load #2400 = #0x960. so i guess it must have been fixed somewhere between `clang-1500.0.40.1` and `clang-1500.3.9.4`. but that is an insane bug. also, `sweep_thread` seems to have the exact same number of instructions under both versions of clang and i'm guessing the only difference is this offset which is kind of wild.
Apple clang versions don't coincide with public clang versions. Apple clang's major versions follow Xcode's. For instance, Xcode 16.1's clang is 16.0.0 (clang-1600.0.26.4).
It's a very weird bug and a very weird debugging story. The description of the change is short, but don't miss the first comment that explains all the details.
I dont get how the C macro with the endless C loop can be called from within scheme, just asis. Without any registration. Is this a chez speciality, or am I missing something?
If I had to guess, they’re probably just expanding the Scheme code into C code during compilation. Also: it isn’t an endless C loop; do{/statements/}while(0) is a common macro idiom for a block of code that requires a trailing semicolon, i.e. one that behaves syntactically like a normal (void) function call. It only runs once because the condition is false.
I'm somewhat lost in the details, but IIUC, you are confused for the "use" of the macro in the file mkgs.ss The fist part of that file is a transpiler, that transpile it's second half from pseudo-scheme to c, and then the c version includes the definition of the macro and uses it https://github.com/cisco/ChezScheme/blob/fc577f234171af80859...
The bug probably wasn’t reproducing on Linux because the clang shipped with Xcode is from Apple’s fork. The version may say “15”, but it was closer to upstream LLVM’s clang 16. There are also changes that haven’t been upstreamed yet and probably some that may not ever be (if my experience updating libtapi in nixpkgs was anything to go by).
i tried reproducing the zipped example on macOS 14.4.1 (23E224) and Apple clang version 15.0.0 (clang-1500.3.9.4) and it looks like the issue is not present on that version.
here are the instructions marked with '<<<<' from `disassem.txt` and my version:
on my version it uses the offset for the first load #2400 = #0x960. so i guess it must have been fixed somewhere between `clang-1500.0.40.1` and `clang-1500.3.9.4`. but that is an insane bug. also, `sweep_thread` seems to have the exact same number of instructions under both versions of clang and i'm guessing the only difference is this offset which is kind of wild.Apple clang versions don't coincide with public clang versions. Apple clang's major versions follow Xcode's. For instance, Xcode 16.1's clang is 16.0.0 (clang-1600.0.26.4).
It's a very weird bug and a very weird debugging story. The description of the change is short, but don't miss the first comment that explains all the details.
I dont get how the C macro with the endless C loop can be called from within scheme, just asis. Without any registration. Is this a chez speciality, or am I missing something?
If I had to guess, they’re probably just expanding the Scheme code into C code during compilation. Also: it isn’t an endless C loop; do{/statements/}while(0) is a common macro idiom for a block of code that requires a trailing semicolon, i.e. one that behaves syntactically like a normal (void) function call. It only runs once because the condition is false.
I'm somewhat lost in the details, but IIUC, you are confused for the "use" of the macro in the file mkgs.ss The fist part of that file is a transpiler, that transpile it's second half from pseudo-scheme to c, and then the c version includes the definition of the macro and uses it https://github.com/cisco/ChezScheme/blob/fc577f234171af80859...