cosmopolitan VS llvm-project

> Using a binary for each platform and chip is the past.

Cosmopolitan sends its regards: https://github.com/jart/cosmopolitan

> Rise above with lightweight container[...]

Ah yes, that famously lightweight way of distributing software, full on virtualised containers, each running an OS.

Case in point:

https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s...

The system call numbers of all the unixlikes are bitwise packed into a single number. There is exactly one of those columns which is stable: the Linux one. Everything else is not part of the binary interface of their respective operating systems.

I've written about how Linux is special in this regard:

https://www.matheusmoreira.com/articles/linux-system-calls

It's a neat hack but I'm afraid it's in grave danger of falling victim to the Darth Vader of OS ABI stability.

https://lwn.net/Articles/806870/

> Program to the API rather than the ABI.

> When we see benefits, we change the ABI more often than the API.

> I have altered the ABI.

> Pray I do not alter it further.

Maybe portable CL binaries soon-ish (in CL units of time, mind you)!

Conditional on https://github.com/jart/cosmopolitan/issues/939 as mentioned in INSTALL

Cosmo gives you what you described above and it’s <10kb

https://github.com/jart/cosmopolitan

llamafiles will run on all architectures because they are compiled by cosmopolitan.

https://github.com/jart/cosmopolitan

  Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.

My comment was based on cloning master yesterday and trying to build redbean but hitting what looks like https://github.com/jart/cosmopolitan/issues/940

Indeed it lioks like the commit you mentioned should have fixed the issue with the pointer having too many bits for the weird kernel used on android and some raspis. Fingers crossed that release works.

Looking at the whole interaction as well as the AI patch (https://github.com/llvm/llvm-project/pull/125602#issuecommen...) the author submitted, I have to disagree. It removes the flag setting altogether and adds useless code. It demonstrates that the author really has no understanding of the code, which may be okay for your weekend SaaS but definitely not for build system code in critical compiler infrastructures. To put it bluntly: This _is_ AI slop.

There's no denying that AI is helpful, _when_ the human has some baseline knowledge to check the output and steer the model in the correct direction. In this case, it's just wasting the maintainers' time.

I've seen many instances of this happening in the support channels for Nix/NixOS, which has been around long enough for the models to give plausible responses, yet too niche for the models to emit usable output without sufficient prompting:

"No, this won't work because [...]" "What about [another AI response that is incorrect]?" (multiple back-and-forths, everyone is tired)

> (If only Clang had some sort of “noinit” variable attribute in order to allow heap to be uninitialized…)

It's attribute((loader_uninitialized)), e.g. https://github.com/llvm/llvm-project/blob/main/clang/test/Se...

> If you think your project will have more than half a dozen developers

https://github.com/llvm/llvm-project/blob/main/llvm/CMakeLis...

How many active contributors does LLVM have? Hmmm

You've invented IR - eg take a look at egress targets in MLIR https://github.com/llvm/llvm-project/tree/main/mlir/lib/Targ...

https://www.amd.com/content/dam/amd/en/documents/instinct-te...

The compiler is LLVM

https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...

It's all there. For the driver/runtime everything is also open and upstreamed into the Linux kernel. The packet protocol isn't well-documented but documented enough that tinygrad managed to build their own driver from scratch.

LLD has a new option "--randomize-section-padding" for this purpose: https://github.com/llvm/llvm-project/pull/117653

Github issue:

https://github.com/llvm/llvm-project/issues/127365

The article is right: it is almost never a compiler bug. I have had that experience of reporting and being wrong. It sucks.

On the other hand, I have a confirmed bug in Cland [1] and a non-rejected bug in GCC [2], so it does happen.

[1]: https://github.com/llvm/llvm-project/issues/61133

[2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448