llvm-project VS cosmopolitan

I think you're correct that it's a big problem that the serious compilers don't actually have coherent internal behaviour, but I think that's a distinct problem which has been masked by the provenance problem in C and thus C++. It meant that real bugs in their software can be argued as "Works as intended" pointing to DR260 rather than anybody needing to fix the compiler.

For LLVM the effect of Rust has been to drag some of these issues into the sunlight, as it did for aliasing problems previously. https://github.com/llvm/llvm-project/issues/45725

Once the GCC work is closer to finished, I expect we'll see the same there.

I disagree that you need to solve the C problem first to solve the compiler problem, and I think it was misguided to start there. You seem to have focused on the fact that exposure is even an option in Aria's implementation, but let me quote: "The goal of the Strict Provenance experiment is to determine whether it is possible to use Rust without expose_addr and from_exposed_addr". Setting PNVI-ae-udi as "the" provenance rule is your end goal for C, but there's a reason it's called the "Strict Provenance" experiment in Rust, the goal is something like what you call PNVI-plain.

APIs like map are key to that goal, Rust has them and N3005 does not.

So like I said, rather than just being a "translation" I think the most that can be said is you've got the same problem albeit in a very different context, and your solutions are related in the way we'd expect when competent people attack similar problems.

> 1. it's insane. nobody would write such an optimization because there's no possible performance gain, and it changes program behavior

LLVM explicitly has an 'undef' constant value which facilitates this optimization. https://llvm.org/docs/LangRef.html#undefined-values

FWIW, the most important reason compilers do this is to decrease compile time. The compiler notices that some code is insane because it's down an unreachable path, and it deletes the code now instead of waiting to prove the path is unreachable. The later optimizations tend to be slower and scale badly with more code in the function, so deleting it earlier will speed up the compile.

> 2. malloc is just a function, it's not treated in any special way

The compiler is full of optimizations that treat malloc and other functions specially. This file implements an analysis, but the results of the analysis is used by transformations. https://github.com/llvm/llvm-project/blob/main/llvm/lib/Anal...

> 3. there's no guarentee this malloc is a per-spec malloc, it can be a user-defined function for which this is perfectly valid

Yep, there's a flag for that mode, `-ffreestanding` which corresponds to freestanding mode in the C89 standard, chapter 2 section 2.1.2.1.

to address the points in order:

1. a specific optimisation pass won't do this, but the combination of several passes written with other intentions can

2 & 3. the C runtime a compiler links with is known to the compiler/linker, and it _does_ usually treat intrinsics like malloc specially

A quick google reveals https://github.com/llvm/llvm-project/issues/52930, LLVM recognising uninitialised memory as 'undef', and needing to treat it as poisoned (IIRC propogation of undef can cause things like separate uses of the variable to not even unify to a single value)

Unfortunately, the necessary restrictions on data accesses to enable parallel execution are not required to hold true in the body of a DO CONCURRENT loop by its botched specification, and neither can they be verified at compilation time. And the committee has known about these problems for nearly six years and has refused to fix them; Fortran 2023 still has them and the topic is not going to be brought up again for Fortran 2028.

So it is possible for a conforming program to be non-parallelizable, due to holes in the default data localization rules, despite the name of the construct and the obvious intent of the long list of restrictions imposed on code in the construct.

I summarized the two specific problems in https://github.com/llvm/llvm-project/blob/main/flang/docs/Do....

No, LLVM definitely still has big problems. https://github.com/llvm/llvm-project/issues/45725 is an example, the symptom in Rust is that you can write what is in effect a pointer comparison in which LLVM ends up claiming that two things are different, although they are also identical...

Same opinion. I have little/no exposure to compilers (yes I know, maybe I'm not the right target) and tried to follow Toy and had to resort to a lot of wikipedia/google just to understand the concepts and terms. And after finishing it I was still a bit confused about how to even get started. I think it could be made a bit more beginner friendly.

I found the standalone example https://github.com/llvm/llvm-project/tree/main/mlir/examples... in the MLIR repo to be very useful, on the other hand.

As for using that combination on non-Windows hosts, I think LLVM's WinMsvc.cmake might help quite a bit - given paths to Windows libs/headers and an LLVM install, it sets up cross-compilation fairly painlessly. Given the size and/or prominence of LLVM, I think it's arguably fairly well-supported and probably not likely to break any time soon.

llvm/llvm-project

This will be much easier using tools like LLVM, but this is the basic outline of creating a compiler.

You just add the -static argument, if you want a fully static executable that can run on any linux distro: ‘g++ -o main main.cpp -static’

You can even go above and beyond with cosmopolitan libc v2, which makes c/c++ build-once run-anywhere: https://github.com/jart/cosmopolitan/releases/tag/2.0

There seems to be some work getting cosmopolitan libc support in Go, but it is not ready like it is for c/c++: https://github.com/golang/go/issues/51900

> Consider offering APE for x64 but then still producing ARM binaries the old fashioned way.

The recent version of cosmopolitan generates ARM binaries for Linux and MacOS (https://github.com/jart/cosmopolitan#arm; mode aarch64). There is also blink that provides the x86-64 emulation layer for (APE and other) binaries on a variety of platforms (https://github.com/jart/blink).

New constants do make compilation a lot easier, but my personal opinion is that the overhead to convert to/from the old constants during runtime is too much.

Look at the list of constants here: https://github.com/jart/cosmopolitan/blob/master/libc/sysv/c...

Every time I used any of these constants, I'd have to load a whole bunch of them into my binary as a large lookup table, and go through that table every time I needed a check in my program. It might not be that slow, but I believe it would definitely be noticeable.

My goal was to make porting easier without changing a lot of source code in either the libc or in the software I was trying to port, and still produce binaries that are close or better in performance. Under those constraints, this gcc patch seemed like the best way to simplify the process.

If I run into enough codebases where SIGHUP is used as an array index initializer, I will probably attempt your suggestion just to measure the tradeoffs. Or you could try it out and let me know if a separate set of constants is better.

There seems to be a socket API in the APE libs though:

https://github.com/jart/cosmopolitan/tree/master/libc/sock

..and that also seems to have WinSocket support:

https://github.com/jart/cosmopolitan/blob/master/libc/sock/c...

I'd like to see them all be more like https://github.com/jart/cosmopolitan. I should note that Go had experimental support for it, but it doesn't look maintained.

check out https://github.com/jart/cosmopolitan/releases

However, it's not true that you can't have native executables that run on both Linux and Windows. It's almost certainly not what we are dealing with here, but there is the cosmopolitan project which creates "a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS".

I bet it wouldn't be too extremely hard to port Vim to https://github.com/jart/cosmopolitan

Nim, or "Cosmopolitan" https://github.com/jart/cosmopolitan