|1 day ago||4 days ago|
|GNU General Public License v3.0 or later||ISC License|
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Changing the Rules of Rust
2 projects | news.ycombinator.com | 17 Sep 2023
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.
Using Uninitialized Memory for Fun and Profit (2008)
3 projects | news.ycombinator.com | 3 Sep 2023
> 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 126.96.36.199.3 projects | news.ycombinator.com | 3 Sep 2023
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)
4 projects | news.ycombinator.com | 28 Aug 2023
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....
A Guide to Undefined Behavior in C and C++
9 projects | news.ycombinator.com | 17 Aug 2023
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...
MLIR For Beginners: A series of articles on the MLIR framework
3 projects | news.ycombinator.com | 16 Aug 2023
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.
How to deal with MSVC in DevOps
9 projects | /r/cpp | 6 Jul 2023
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.
Learn to write production quality STL like classes
4 projects | /r/cpp_questions | 28 Jun 2023
Dobri projekti na Githubu za ucenje
7 projects | /r/CroIT | 26 Jun 2023
I'm wanting to write my first compiler, but getting a little bit mixed up in general.
3 projects | /r/Compilers | 24 Jun 2023
This will be much easier using tools like LLVM, but this is the basic outline of creating a compiler.
Java 21 makes me like Java again
22 projects | news.ycombinator.com | 16 Sep 2023
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
Patching GCC to Build Portable Executables
> 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:
..and that also seems to have WinSocket support:
Is there any high level programming language whose executable generated on one platform(OS) and runs on other platforms as well, if the machine/architecture is literally same.
2 projects | /r/ProgrammingLanguages | 25 Jun 2023
How can go build to other operating systems
3 projects | /r/golang | 8 May 2023
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.
How do you build cross-platform C programs?
3 projects | /r/C_Programming | 29 Apr 2023
check out https://github.com/jart/cosmopolitan/releases
Can I really run an exe natively without Wine?
2 projects | /r/archlinux | 23 Apr 2023
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".
Boot to Vim, Vim as PID 1
3 projects | news.ycombinator.com | 22 Apr 2023
I bet it wouldn't be too extremely hard to port Vim to https://github.com/jart/cosmopolitan
New language suggestion to old time Gopher
5 projects | /r/golang | 1 Apr 2023
Nim, or "Cosmopolitan" https://github.com/jart/cosmopolitan
What are some alternatives?
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
src - Read-only git conversion of OpenBSD's official CVS src repository. Pull requests not accepted - send diffs to the tech@ mailing list.
Lark - Lark is a parsing toolkit for Python, built with a focus on ergonomics, performance and modularity.
SDL - Simple Directmedia Layer
libc - libc targeted for embedded systems usage. Reduced set of functionality (due to embedded nature). Chosen for portability and quick bringup.
luastatic - Build a standalone executable from a Lua program.
open_iot - ocpu
Graal - GraalVM: Run Programs Faster Anywhere :rocket:
linux - Linux kernel source tree
v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io