If a compiler's work is essentially translating source code into machine level code, can there be any glitch in a compiler, i.e. a faulty "translation?"

The same goes for an interpreter: can it fail to output the required content sometimes?

I have not heard of any bugs in compilers/interpreters, but do they exist?

  • 8
    in development they will most definitely exist just look at the bugtracker on any open source compiler Commented Jul 8, 2013 at 14:36
  • 7
    I have not heard of any bugs in compilers/interpreters, but do they exist? I found the mailing list for bugs in the gcc compiler: gcc.gnu.org/ml/gcc-bugs Commented Jul 8, 2013 at 15:07
  • 47
    This isn't a really good question, it just asks something that is common sense.
    – user7007
    Commented Jul 8, 2013 at 15:10
  • 12
    None of the comments or answers so far address the likelihood of encountering a compiler bug. Be sure to rule out errors in your own code first. Commented Jul 8, 2013 at 16:08
  • 6
    Short answer: definitely. While IDEs and compilers are typically exercised within an inch of their lives before they ever see the outside world, there's always a corner case somewhere that a developer being a little too clever will find.
    – KeithS
    Commented Jul 8, 2013 at 16:27

10 Answers 10



You tend to find them more in languages that are actively being developed than in those that are relatively mature (and thus don't see a lot of change on a frequent basis). This is probably why most languages are released at various 'stages' of stability. A nightly build is far less likely to be stable than a release candidate, which itself is less likely to be stable than a fully released and actively used version.

Luckily most of these languages (especially those that are open source) will have a public bug tracking system that you can submit reports to.

In my own experience, I ran into a fairly obscure but severe bug in Scala on Windows. I submitted my findings to the bug tracker and the issue was fixed fairly quickly. In that case, the language developers were smart enough to include a helpful note in the error log output, suggesting that what I'd run into was in fact a compiler error, and said where to submit the report.

  • Hope you don't mind; I added a new paragraph (pending approval) which I thought might be relevant. Not only might a compiler contain bugs, it might contain malicious code.
    – Andy
    Commented Jul 9, 2013 at 10:03
  • @Andy it looks like one of the moderators rejected it as something that should be a comment or separate answer.
    – KChaloux
    Commented Jul 9, 2013 at 12:51
  • Not just "yes", but "hell yes!" :-)
    – Hellion
    Commented Jul 9, 2013 at 14:45
  • C is both mature and actively developed. So is C++. So is Java. etc..
    – djechlin
    Commented Nov 10, 2014 at 5:29

In layman's words:

All programs can have bugs.

Compilers are programs.

Ergo, compilers can have bugs.

  • 55
    More worrisome: Debuggers are programs. Therefore, debuggers have bugs. Commented Jul 8, 2013 at 14:52
  • 19
    @jozefg: So how do you debug the debugger? Who watches the watchers? Commented Jul 8, 2013 at 15:04
  • 16
    @FrustratedWithFormsDesigner The watcher watchers, duh. Commented Jul 8, 2013 at 15:14
  • 9
    @JoelFan Since I wrote "can have", that exception is covered. If you say "have" you have to specify that you are referring to non-trivial programs only. By saying "can have", you don't have to. Commented Jul 8, 2013 at 16:43
  • 8
    "Hello world" programs can have bugs if its complied with a bugged compiler.
    – wtsang02
    Commented Jul 8, 2013 at 17:50

There can bugs even in hardware; a famous example is the Pentium FDIV bug. Without doubt there is the possibility that the compilers contain bugs.


Compilers and interpreters are software too, and thus they aren't free from any of the problems of other software.

This is an example from a compiler as recent as MSVC 11 (2012), and here's an article on how they test the backend.


Of course, because compilers are software.

In 2005, I had a piece of code fail in a highly critical piece of software I had written for a large company. Since it cost the company literally millions of dollars to rectify, they of course launched a big-ass investigation.

Thankfully (from my perspective), the issue turned out to be a compiler issue in Delphi. In the try finally block, the return value of a function was destroyed, and resulted in absolutely random results back to the caller. This was documented, and acknowledged by Borland.

.NET was well known to have literally hundreds of different memory leaks, particularly in its early implementations.

I would contend that there is no such thing as bugless software. Compilers are no exception. They are, though, tested more thoroughly than most business software, and are consumed by smart, critical, contentious people, so their track record has actually, on the whole, been pretty good.

  • There is "formally verified" software. It is mathematically proven to work. Occasionally even formally verified code has bugs. IIRC Java's quicksort implementation was formally verified, but that did not account for overflows. Commented Jul 9, 2013 at 1:57
  • 1
    What was the software? C'mon :)
    – Rocklan
    Commented Jul 9, 2013 at 5:44

Not only bugs, but also deliberate malware.

The "login" trojan implemented by Brian Kernighan to the original Unix C compiler is the most well-known of these; the article http://cm.bell-labs.com/who/ken/trust.html has some background on this.

  • 2
    Is it clear that that was actually implemented? Commented Jul 8, 2013 at 22:20
  • This is a quite interesting topic, but not at all related to this question.
    – user7043
    Commented Jul 8, 2013 at 22:38
  • @delnan I disagree; at the heart of the question seems to be "how much can I trust my compiler?"
    – Andy
    Commented Jul 9, 2013 at 15:10

Yes of course like any software compilers have bugs, for example the gcc bug list is here



Also, not only with compilers, but also with Interpretors/debuggers, and any 3rd party software tool.

We are currently using some 3rd party software, and have been having some of the issue. Sometimes they thank us, for finding and reporting a bug. :)

Some of them have some memory leaks too, which leads to crash. The important question here could be, how to determine if the 3rd party tool, or the compiler has bugs for your application to work correctly?


Compiler is a program that reads a program written in one language (the source language) and translates it into an another equivalent program in another language (the target language), mostly machine language.

There are different phases of compiler through which your source language code is scanned line by line. There is a symbol table which keeps the track of all Keywords which are scanned for in source language code.

Phase 1 : Lexical Analyzer - reads all the character in source program and forms the logical separation of tokens (int, char, float, if-else,for,while etc.)

Phase 2 : Syntax Analyzer - analyze the structure of stream of tokens. Hierarchical parsing of expressions which includes postfix/prefix etc. (a=b+c*d)

Phase 3 : Semantic Analyzer - Type checking of tokens (integer to real, float etc.) and many things like operator precedence etc..

Phase 4 : Intermediate Code Generator - a=b+c*d-e(temp1=c*d, temp2=temp1+b, temp3=temp2-e)

Phase 5 : Code Optimization - Various Analysis (control flow, data flow, transformations)
which eleminates : Redundancy code, Constants propogation, Partial dead code, common subexpression, Loop invariant code

Phase 6 : Code Generation - Generation of target code (Mostly Assembly Language) putting values in Registers

All these phases are nothing but well written programs and there could be N number of flaws in that..


Of course, compilers are just programms and their authors are idiots too :). Even language specification can have a bug. Example: c# + foreach + lambda.

Or in Python, bug in interpreter: Compiling evil ast crashes interpreter.

Well, if you want to look on bugs in compiler/interpeter -> look at php. There is a famous bug with integer overflow. First fix started from if (size > INT_MAX) return NULL;. Continuation of the story.

  • Compiler writers are not idiots. As compilers are quite complicated the barrier to enter the field is also substantially higher. So we can expect the people who write them to not commit mistakes as average guys do. Commented Jul 9, 2013 at 11:47
  • The foreach / lambda is not a bug, its comes down to a specific and conscience design decision made before lambdas were added.
    – Andy
    Commented Jul 9, 2013 at 15:12
  • @Andy, as I know, no one has knowed what problems this decision will cause. Why not bug? Commented Jul 9, 2013 at 16:08
  • @jszpilewski do you see a smile after that text? Commented Jul 9, 2013 at 16:09
  • 1
    I suggest you re-read the OP, since his question is not about whether specifications can have bugs, its about whether COMPILERS can have bugs. Since the C# compiler matched the specification, the compiler did not have a bug. I also suggest you re-read your own Wikipedia quote "A software bug is an error, flaw, failure, or fault in a computer program"
    – Andy
    Commented Jul 10, 2013 at 19:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.