llvm-project VS gcc

This reminds me of a similar issue in LLVM's `raw_svector_ostream`. Before a 2015 commit https://github.com/llvm/llvm-project/commit/3d1173ba1a53cab0... ,

Huh? Quoting a bit more from the article:

> [W]e find this in ARM.cpp:

> trapInstr = {0xd4, 0xd4, 0xd4, 0xd4};

The only thing left to explain is that the trap instruction is used as padding, but you can’t tell from here if that’s obvious or not. Opening the actual code[1], we see that the occurrences of trapInstr are all along the lines of

> void ARM::writePlt( /* ... / ) {

> / ... */

> memcpy(buf + 12, trapInstr.data(), 4); // Pad to 16-byte boundary

which isn’t the absolute best, but seems clear enough (if of course you know what a PLT is, which you should if you’re writing a linker).

I do think this merits an explanation that we’re using (what’s intended to be) a trap because the traditional option of using a nop makes ASLR less effective. But then the commit message you’re quoting doesn’t mention that either.

[1] https://github.com/llvm/llvm-project/blob/b20c291baec94ba370...

Certainly compiler developers are only human, and many of them write C++ so they're humans working with a terrible programming language, I wouldn't sign up for that either (I have written small contributions to compilers, but not in C++). I still don't see "any excuses". I see more usual human laziness and incompetence, LLVM for example IMNSHO doesn't work hard enough to ensure their IR has coherent semantics and to deliver on those semantics.

The compiler bug I'm most closely following, and which I suspect you have your eye on too is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119472 aka https://github.com/rust-lang/rust/issues/107975 https://github.com/llvm/llvm-project/issues/45725

But it seems like it's just that everybody fucked this up in similar ways, that's two different major compiler backends! I wouldn't be surprised if Microsoft (whose code we can't see) find that they don't get this quite right either.

My ideal array language is one in which array operations are function compositions, since arrays are functions. A functional view of array expressions naturally minimizes needless temporaries in most cases.

See https://github.com/llvm/llvm-project/blob/main/flang/docs/Ar....

Lightweight UI for Github? (Idk if that exists).

e.g. client requests https://github.mx/llvm/llvm-project, your server fetches the data from https://github.com/llvm/llvm-project (using an API or scraping the site), and renders it in a cleaner UI with less HTML and JavaScript.

It would be useful for slow/outdated devices and places with low internet bandwidth. The URL concept is similar to https://github.dev/llvm/llvm-project which opens the project in a web-hosted VSCode (so vaguely the opposite approach).

- Testing: llvm-lit tests validate the analysis by checking the generated facts.

Example:

[LifetimeSafety] Introduce intra-procedural analysis in Clang

- commit: https://github.com/llvm/llvm-project/commit/3076794e924f

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

> still is the main company behind LLVM.

lol people really say whatever comes to their mind around here don't they? I'm pretty sure all of the companies associated with these targets would strongly disagree with you

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

The most interesting part of this post is the bit about half way down, where Alex uses Claude to help identify a missing compiler optimization in LLVM... and then uses Claude Code to implement that optimization and gets a PR accepted to LLVM itself! https://github.com/llvm/llvm-project/pull/142869

it's mostly upstream now, no need to dig around in their repos

https://github.com/llvm/llvm-project/tree/main/clang/tools/c...

I'm not sure I understand what your trying to say here WRT to cpu microarch optimization with multiple cpu microarches in the machine. Maybe something about SMT/hyperthreading? But that doesn't appear to be what your saying either.

AKA: I'm talking about the uplift one gets from say -march=native (or your arch of choice), FDO/PGO and various other optimization choices. Ex: Instruction selection for OoO cores. The compiler can know you only have to functional units capable of some operation with coreX, and your codes critpath is bottlnecked by those operations and can adjust the instruction mix to (mis)use some other functional units in parallel. Two units doing X, and one doing Y. Or just load to use latency, or avoidance of certain sequences, etc.

Those optimizations are tightly bound to a given core type. Sure modern OoO cores do a better job of keeping units busy, but its not uncommon to be working around some core deficiency by tweaking the compiler heuristics even now. Trolling through the gcc machine definitions:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i38...

Here's the GCC implementation of `std::function`:

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...

I'm with OP here.

Interestingly, the complete implementation of strtol [1] is shorter than this wrapper. If you don't like strtol's API or error handling, just implement your own.

[1]: https://github.com/gcc-mirror/gcc/blob/master/libiberty/strt...

It’s hard to overstate the amount of service Ian provided to the Go community, and the programming community at large. In addition to gccgo, Ian wrote the gold linker, and maintains huge swaths of the gcc codebase [0].

I’ve had the pleasure of trading emails with Ian several times over the years. He’s been a real inspiration to me. Amidst whatever his responsibilities and priorities were at Google he always found time to respond to my emails and review my patches, and always with insightful feedback.

I have complicated feelings about the language that is Go, but I feel confident in saying the language will be worse off without Ian involved. The original Go team had strong Bell Labs vibes—a few folks who understood computers inside and out who did it all: as assembler, linker, two compilers, a language spec, a documentation generator, a build system, and a vast standard library. It has blander, corporate vibes now, as the language has become increasingly important to Google, and standard practices for scaling software projects have kicked in. Such is the natural course of things, I suppose. I suspect this cultural shift is what Ian alluded to in his message, though I am curious about the specific tipping point that led to his decision to leave.

Ian, I hope you take a well-deserved break, and I look forward to following whatever projects you pursue next.

[0]: https://github.com/gcc-mirror/gcc/blob/master/MAINTAINERS

> (and of course eventually dropping support for Motorola 68010 on which the Tektronix 4404 is built)

I don't think it ever did? Looking here[1] it still seems to be supported

[1]https://github.com/gcc-mirror/gcc/blob/master/gcc/config/m68...

There are some open source C compilers such as the GNU C compilers (https://github.com/gcc-mirror/gcc) and Clang (https://clang.llvm.org/get_started.html).

There are also proprietary C compilers such as the Microsoft's C compiler (https://visualstudio.microsoft.com/vs/features/cplusplus/) and the Intel C compiler (https://www.intel.com/content/www/us/en/developer/tools/onea...).

There are many others: https://en.m.wikipedia.org/wiki/List_of_compilers#C_compiler...

Most mature C compilers will specify what version(s) of the C standard they implement so developer users can know what features are available. Many C compilers also implement non-standard extensions to the C language and libraries to be more competitive, overcome language shortcomings, or provide for specialized needs or development targets (e.g. features for embedded targets).

But I'm still sure that there are several UB's in my code :)

[1] https://tunglevo.com/note/an-optimization-thats-impossible-i...

[2] https://github.com/gcc-mirror/gcc/blob/d09131eea083e80ccad60...

[3] https://github.com/llvm/llvm-project/blob/4468d58080d0502a05...

I was hoping GCC would do the same, leaving the decision about the value of '\n' to GCC's compiler, but apparently it hardcodes the numeric values for escapes[1], with options for ASCII or EBCDIC systems.

[1] https://github.com/gcc-mirror/gcc/blob/8a4a967a77cb937a2df45...

GCC github-mirror GCC Documentation GCC Internals Mannual Installing GCC