claude-code-mcp VS llvm-project

Claude Code as a tool call, from Copilot‘s own agent (agent in an agent) seems to be working well. Peter Steinberger made an MCP that does this: https://github.com/steipete/claude-code-mcp

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...