Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's not me, it's the compiler

parsa.wtf

Post reply on HN
Print view View original

11–20 of 27 posts

Re: It's not me, it's the compiler

#11

Post by jpollock »

recursivedoubts wrote: post #2

interesting story as an aside, I think the original code, with the if statement, was clearer and would be easier to debug, etc, even if it was a bit longer

I prefer the second. :)

It's about the cognitive load and having to follow branches.

The second version minimizes the cyclomatic complexity, taking it to 1. The reader doesn't have to keep the if statement in mind when reading through the code, and doesn't have to worry about all the ways the code can get there if they want to modify it (e.g. to add logging, metrics, other logic).

Whether or not consume should be a separate function depends on how often it's called. Here, I'm guessing it's once. :)

Re: It's not me, it's the compiler

#12

Post by rtpg »

> The issue was labeled p-critical and i-miscompile, out of +61K rust issues there only 7 (including this one) that are both p-critical and i-miscompile, to me those are the most dangerous kind of bugs a compiler can have, given that they violate the contract between the programmer and the language. They show that not every safe code you write is safe. And also more generally there are only 247 p-critical issues to begin with.

I don't mean this in a snarky way or the like... and I guess the fact there are so few of these are a good indicator that the current processes are working decently well... but I would be very curious on a post-mortem from maintainers on how this bug got through. Miscompiles feel like the scariest sort of thing.

Maybe the deep and dark secret is simply that compiler optimizations are just extremely prone to mistakes and we all are just lucky enough that most messed up optimizations will break _something somewhere_ early enough to not get merged.

Re: It's not me, it's the compiler

#13

Post by fusl »

WJW wrote: post #6

If the author is here, typo in the second paragraph: "eariler", should probably be "earlier".

There are probably a couple more typos in this ("momenet" being another one). It's very refreshing to see blog posts not being written by LLMs for once.

Re: It's not me, it's the compiler

#15

Post by jdw64 »

jackmott42 wrote: post #9

I started programming at ~8 and as a kid you often are sure the compiler is wrong, and it never is. (maybe once, have a vague memory of it) Then years later I started playing with Nim when it was still in beta, I think I found 3 compiler bugs in a few weeks! Reported them all, all got fixed! And then a few years later found a bug in LLVM, doing weird stuff with Rust and SIMD intrinsics. Was difficult to even communic…

So you've been talented since you were a kid, wow

Re: It's not me, it's the compiler

#17

Post by csande17 »

Surac wrote: post #16

can someone explain what the self.0 means? im not a rust speaker

Rust has a feature called "tuple structs" where the properties of the struct are accessed by numeric indices instead of names: https://doc.rust-lang.org/book/ch05-01-defining-structs.html... / https://doc.rust-lang.org/book/ch05-02-example-structs.html#...

In most other languages this would be written as "this.current_index" or some other property name.

Re: It's not me, it's the compiler

#18

Post by rcxdude »

norir wrote: post #4

This feels like it should have been a warning rather than an optimization in the first place. In my opinion, dead code elimination should only be done during link time optimization where it can be proven that branches are not taken given the whole program information. If there is an unused assignment regardless of the branch, the compiler could emit a warning so the user can do their own dead code elimination, or cho…

> If the compiler can optimize a piece of code, it can also show the user what it thinks the optimal code would be so that they can rewrite it themselves, if they so choose

This is not straightforward. Apart from the mapping from a several-layers-deep optimization to the source level being very difficult, it may not be even representable in the original language. And even if it is, it may require complicating the code significantly. Part of the point of compiler optimization is so that you can write straightforward code and still have it be fast.

Compilers will often warn on dead code, but only at fairly early stages of translation where it's obvious that something is definitely dead code in all possible contexts and the fix is obvious. These rules are different to what the optimizer actually uses much later on in the pipeline.

Re: It's not me, it's the compiler

#19

Post by Semaphor »

Still looking fondly back to when I was studying back in ~2006, and my C program on some (I think?) ATMega device (probably not the latest version of the compiler? I really can’t remember the details anymore) device didn’t work the way I thought it should. Called the professor over. He looked at the assembly and realized the compiler was modifying a variable outside the loop for some reason that was modified inside with the C code. So before I even heard of "It’s never the compiler", I learned that sometimes it actually is the compiler ;)

Re: It's not me, it's the compiler

#20

Post by Agingcoder »

Compiler bugs are surprisingly common - most people simply never notice them. Whether these bugs are major or not is a different topic.

If you have a very large scale test suite for your application, a large codebase, and exert most compiler features including the optimizer , you’ll probably find a few every time you upgrade .

Post reply on HN