Putting reference in quotes and saying "Here's the source code for Salesforce." strongly implies you think it was given access to GCC source, not that it was told if the program works when a set of TUs is built with GCC.
I would be more impressed if Claude had thought to do this itself.
You have wildly misunderstood the article. GCC was used as a known good compiler to isolate which source files the new compiler had issues with. This is standard practice in compiler development when you have a known working compiler.
It's a bad compiler, but impressive it works as well as it does.
Hello pony people! We're cooking in Northern California
To sign up for our newsletter and learn more about who we are, check out our website!
bronyexpo.com
oh, no, that's not safe to eat
I made a flat plush.
It also even works for C, so C++ and C can be compatible here.
I'm thinking of proposing module maps for standardization. It's clear to me that they are the right solution for telling the toolchain which headers should be header units. Since the system headers need them too, it doesn't make sense for each compiler to have their own version.
Include translation mostly solves the duplicate definition problem, although sometimes the compiler does need to type merge. It definitely is a big task to deploy header units in a large codebase, but it's significantly less effort than moving everything to named modules.
The huge difference is that PCH's are generally only allowed to exist once per TU and if anything changes the whole thing needs to be rebuilt, while header units form a DAG. Given well written headers, it's almost transparent to switch to header units.
There's more toolchain and build system work needed to make this generally available to people, but nobody seems interested in working on it.
Clang modules have been made to work with distributed build systems, but I'm not aware of any publicly available build systems that currently do. Although there seems to be some effort in GN: gn.issues.chromium.org/issues/42440... and chromium.googlesource.com/chromium/src....
Header units are new in C++20. They are a way to treat a header as a separate translation unit, and then import it into any other TU that uses it by converting `#include` to `import`. Clang has had clang modules which are nearly the same thing for ~10 years now, and some companies are using this.
I wish people weren't so against header units. They are by far the fastest way to get the build perf benefits of modules as they don't require rewriting all your code. It's also equivalent to what Apple, Google, Meta, and Microsoft are using in prod.
The capitalization is the worst part here.
Well, you were likely playing on a 640×480 or 800×600 CRT, so it was better. It's a lot different on a 4k LCD.
Yeah, I have a room at the very end :(
Drawing of a ponified version of the LLVM dragon with its hooves together in a pleading pose.
LLVM pone wants to make more assumptions about your code.
By @rivibaes.bsky.social
And here I thought canonicalizing -D and -U options would be easy:
godbolt.org/z/3dKW9ro9G
So apparently both file locking and named semaphores are just fundamentally broken in the Unix ecosystem.
apenwarr.ca/log/20101213
membarrier.wordpress.com/2020/07/16/t...
Also Android just doesn't implement named semaphores.
I just want simple, reliable, and portable cross process sync :(
What would your preferred API be here? C doesn't have non-trivial output iterators, so having non-bounded APIs is always going to be an issue, while in C++ it's a nice way to allocate the correct size without double formatting.
Would be better if you couldn't pass a UB on overflow iterator though.
3 floating shelves filled with My little pony plushies
Added some more plush display space.
`poison`
Thanks. I was searching for other LLVM/compiler people and saw it.
Not just the LLVM dragon, it's a ponified version of the LLVM dragon I had commissioned.
