This is just plain wrong.

It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune.

Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be the OS kernel, or even the hardware (CPU, USB controller, network card, ...). It's all chock-full of bugs.

I've hit a handful of miscompilations while writing boring JavaScript web apps, some only when the JIT kicks in for extra fun. I have a handful of outstanding Linux kernel bugs, one of which cause memory corruptions, has existed at least since 2.6 and is dead simple to reproduce. I have a significant GCC performance degradation bug, triggered by calling "pthread_exit(3)" after an infinite loop. I've had what seemed to be software problems turn out to be PCIe problems.

You might think that, as a developer, you're building a card-house on a solid foundation. But no, it's card-houses all the way down.

“It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compiler bug, there are orders of magnitude more who think they did, but didn't. If you start saying "it could be a compiler bug," you're encouraging them to waste their time.

> When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct.

I agree wholeheartedly. Saying "it is never a compiler error" doesn't preclude this; it encourages this behavior. Even thinking "it could be a compiler error" invites laziness.

> Even thinking "it could be a compiler error" invites laziness.

Or worse it could invite curiosity and now you are spending time wondering how could you tell if it's a compiler bug and how would you go about debugging it.

Or worse it could deter curiosity and now you are spending time complaining about compiler bugs instead of debugging your code.

If it's really a compiler bug, you'll find out in the process of debugging your code.

Laziness invites efficiency.

I strongly disagree with your point of view: "it is never a compiler error" not only precludes suspicion of the lower levels—voicing your suspicion of problems in lower layers will generally result in ridicule!—but it reducing critical thinking, bars people from looking into "complicated" projects, and makes them overall less efficient and skilled developers. I also disagree that encouraging a bit of wasted time is a problem. What is a few hours, or even days "wasted" learning your lesson once and for all if it greatly improves your debugging skill and efficiency? You do not learn without mistakes.

"It is never a compiler error" is a detrimental mindset to have, in that it suggests a mentality where you shut your eyes for anything you did not author. After all, it is too complex, too well-tested, too well-designed, and implemented by much smarter people than you. Compiler, library, application, hardware, train, bridge, it doesn't matter.

Not only does this mean that you often won't find the bug you hit, as you won't start instrumenting the faulty LargePopularLibrary—after all, it obviously can't be to blame—but it also means that you won't as much as read library|compiler|kernel|etc source code, much less do development on it, as you think it is above you, despite it by no means being some magical black art.

"It could be a compiler error" invites you to consider all possibilities. Immediately blaming the compiler without reasonable evidence would, despite such a mantra, be a result of terrible debugging skills. These debugging skills should be improved through other means than intentionally teaching falsehoods, and if the subject is not an entirely lost cause, it should correct itself in much more valuable ways if a little time is "wasted" on improper debugging.

Teach proper debugging techniques instead of lying to others, or yourself.

You seem to be arguing against a straw-man, sir.

The OP simply said that the chances of finding a compiler bug are small. You seem to have found a few minor bugs, and that's cool, but how does that change the fact that chances an average C developer finding a compiler bug are minuscule? There are probably around a million C developers, do we even have one compiler bug per 10 developers?

> You seem to have found a few minor bugs, and that's cool

I'm sorry, how are total miscompilations and memory corruptions "minor bugs"?

I am arguing against the mentality of dismissing compiler bugs, with the idea that "you will never hit one". Hence my examples of when I hit them during something as high-level as web development. I am not arguing that you'll hit such bug every day, or even every month.

I only have myself and those around me as reference. I have been a software developer for less than 10 years, but with the current total, I have been hitting a few "lower layer" (vm, stdlib, compiler, kernel, hardware) bugs a year.

Maybe I'm just "unlucky". If you want to find real numbers, take a look at GCC/LLVM/libstdc++/glibc/linux bug tracker statistics. I'm sure you will be surprised.

I worked a compiler backend for 5 years. Despite the insane amount of testing, fuzzing, standards tests, etc that we did, there were always bugs coming in, and not always in code that looked dodgy. Sometimes an optimization interacts with another in JUST the right way to cause incorrect code to get generated.

Honestly, I'm surprised that I haven't run into more of them in the wild.

> If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are.

I'm one of those that routinely find a bug in a library during the very first use of its API. Every "quick weekend project" turns into "let's learn the build system of this library and send a patch/bug report to the maintainer".

Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A?

Get into an industry that values Q/A a lot. Aerospace, rail, nuclear power plants. Q/A doesn't have to be a dead-end job, career-wise.

Go into security and turn that free bugreport into big budget bug bounties ;)

If you can find bugs in libraries used in IOS/Android or something, that's worth money and gives you the chance to increase security for millions (billions?) of people.

I have a similar thing with typos. Give me a page of printed text, and there's a surprisingly high chance I will spot a typo within the first few seconds of looking at the page, no matter where the typo occurs on the page.

(Might be confirmation bias, but I have been proofreading a lot of theses for my friends while in college, so it might be trained.)

Your superpower is both a blessing and a curse.

It's likely that your weekend projects are things you find interesting and it seems likely that the things you find interesting are bleeding edge. It's never going to get better. On the other hand, any good dev team would value someone who can not only find the bug, but patch it.

You need to get somewhere where using the latest and greatest is encouraged..

Yeah libraries are a different thing. I find bugs in python modules all the time.

Might make you suited to security consulting?

<quote>Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A? </quote> What would you say, if I told you that this superpower was not basic Q/A? because basic Q/A is what the compiler is passing, all the time. The part you meant with vigour was the <b>job</b> part right? how do you make somebody want your awesome enough to pay you a living wage? It's either apple or Intel, because they are the two people financially vested in llvm.

If you're the kind of programmer who inputs HTML into a comment system that doesn't support it...

I'm not in QA. You obviously head the snark department very well. Expect promotion, but alas, not much more pay.

The chance isn't that small, many people stumble over them and just use the first workaround SO turns up or think its actually their fault and work around it in other ways.

I had some bad experiences with visual studio's compiler recently (last two years.) I was working on OpenGL code and discovered a couple different constructs that would crash the compiler. The first time I figured it was a fluke, but by the third distinct case I became rather alarmed; the code should have produced errors, not compiler failures. I concluded that MS's compiler is decidedly less robust than GCC and clang; I've seen one compiler crash from a release GCC compiler in the last 10-odd years.

When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there.

Eventually, someone (Natalie) moved the comment below the assignment, and it worked normally. I tried putting it back above, and it wouldn't compile. Can't remember what happened if I left the moved comment in place and put another above the assignment. I found two like that - one in CodeWarrior, one in Turbo Pascal a few years before that simply returned "error 0: no error."

It wasn't anything complicated in either case, just very basic stuff.

I've used a lot of C/C++ compilers over the years, and the two compilers marked in my memory as having enough bugs to be noticeable and disturbing were Visual C++ 4.1 (so notably bad that MS essentially apologized for its screwup and conceded that 4.2 was largely about fixing 4.1's problems) and CodeWarrior for Mac (pretty much any version, I think...I never tried the Windows version, but the thought of it makes me shiver).

CW had a pretty nice environment to develop in compared to its contemporary competitors, but it just didn't have a solid compiler.

This was pretty common in Turbo Pascal, your program would just suddenly stop working when you added a new blank line. (It would compile, but something would usually be off in the output causing the program to fail or crash).

Removing the offending line or adding a different mix of blanks/instructions would get you back to a working state again. Very frustrating.

Something similar happened to me a while back in Mono/C#. I think it was the order of assignments for an unused variable changed the results of the code. Something like:

    int x = 0;
    int y = 2;
    DoSomething(); // Didn't run with x before y

I can't recall if I ever reported it or bothered looking into it, but a friend ran into a similar issue around the same time and it was really confusing, but it was resolved by changing some configuration (different compiler version or flags I think).

Only other time I bumped into it was in Idris, which is to be expected frankly.

From what I remember of a deep dive post I read on this once, the ordering type bug / no-bug situations tend to be the result of incorrect optimizations. Changing the ordering will sometimes make the code look just different enough to go down a different (not bugged) optimization path.

If you ever catch them still there with a "no optimizations" flag, then that's a pretty serious bug!

Any chance the line endings were different and that was somehow messing it up?

Yeah working on FreeSWITCH, upgrading to VS2015 and we encountered an issue with a long series of else branches. Ended up having to split and nest for the code to compile.

In 2012 I used a C compiler where using printf to output a 64bit integer would corrupt the stack.

Not that hard to stumble upon, but it took us awhile to figure out what the heck was going on.

That sounds like a bug in the standard library... not a bug in the compiler.

Not necessarily. Could be a problem with passing 64-bit values to varadic functions generally. I could definitely imagine this happening on a 32-bit platform.

This has bitten me on QNX. I was porting UQM for fun, and it was failing when entering a dialogue,

Turns out, on QNX you can't pass short int into variadic function, which is expected behavior as far as C is concerned (you should only pass int or full size types), but it worked on every other arch so it took me a while.

The generated assembly was garbage, so I assume it was a compiler bug. It also got fixed in later revisions, but since the compiler is shipped with the CRT... :)

I don't actually recall if we were using the shipped CRT or not, I'm guessing only minimal parts of it were used, if any, since embedded projects tend to write their own subset of the needed standard library functions.

> If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are.

A Swift developer?

Just yesterday I found myself compiling a new part of code in increments because all of the new code together wouldn't compile but adding the code and import first, compiling it before adding @UIApplicationMain would compile just fine. Exactly the same code that didn't build before.

I can't imagine what I would have done if I would have trusted that this was my error because the compiler would not make mistakes.

Though nothing compared to Swift 1.x, things tend to work generally and if the compiler does crash it'll crash on weird programming mistakes (like referencing type(of: self) before init() was called)

Nothing magical about writing a compiler. The humans that make them introduce bugs, like with all software.

A compiler in particular is a very extreme case. Most software is used to its fullest extent by its developer, 90% of bugs are likely to be found by said developer in their normal usage. Another step out, library developers often use their work, but often build in functionality they're not as interested in by request or as a result of generalizing beyond their specific use cases. They might not be the heaviest users of that software, and so aren't as likely to find some of the bugs.

Compilers are the most extreme case. Anything Turing complete is almost certain to have vast swathes of functionality which aren't used by the developer. If a compiler doesn't already have a large user base, then unless you're using it exactly like someone else has, you're almost guaranteed to find some bugs. Honestly that's true for most software, going back to the maxim "don't be the biggest user of any given software unless you're already capable of writing it yourself."

I remember reading that TeX uncovered a remarkable number of bugs in Pascal compilers back in the day.

That was true-er when by compilers one meant GCC or some such.

Now everybody and their dog write compilers and transpilers for young and/or obscurer languages (I'd include Go and Rust in there), and with the immaturity of these environments compiler bugs are a fact of life.

Nope. Wasn't true then, either. Found bugs in Lattice, gcc, egcs, Borland, Aztec, and probably a few more that I'm forgetting.

They're never common, but "it's never the compiler" doesn't apply either. It is, however, a helpful reminder that the most likely source of problems is with the author of the code :)

Care to explain the "bugs" you found?

Obviously broken code generation, in the sense that the code provably does not behave as it should under the spec. Usually as a result of optimization gone wrong.

If you're asking for actual examples - sorry, you're out of luck. The 80's and 90's are a bit too long ago for me to remember details.

If you prefer to believe in the magically flawless compiler fairy, knock yourself out.

Yep, I was going to comment that if you write your own compiler you'll find plenty of bugs, which is the same point.