27

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?

Witch-King
  • 477
  • 4
  • 7
  • 8
    in development they will most definitely exist just look at the bugtracker on any open source compiler – ratchet freak Jul 08 '13 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: http://gcc.gnu.org/ml/gcc-bugs/ – FrustratedWithFormsDesigner Jul 08 '13 at 15:07
  • 47
    This isn't a really good question, it just asks something that is common sense. –  Jul 08 '13 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. – Dan Pichelman Jul 08 '13 at 16:08
  • Related: http://programmers.stackexchange.com/q/51966 – Karl Bielefeldt Jul 08 '13 at 16:16
  • 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 Jul 08 '13 at 16:27
  • This is a franky bizarre question. If compilers can't have bugs then why would anything advance beyond version 1.0? – Gaius Jul 08 '13 at 19:04
  • 2
    @DanPichelman Very true! As a rule of thumb: when you already spent the whole week tracking down one weird behaviour of your code and you checked everything, produced a minimal example and you know exactly that you didn't do anything wrong and thus it *must* be a compiler bug ... there's still a 100% chance that you're going to make an utter fool of yourself when reporting the bug. – Christian Jul 08 '13 at 19:12
  • They can even have bugs which are not present in the source, as [Ken Thompson presented](http://cm.bell-labs.com/who/ken/trust.html) – ugoren Jul 08 '13 at 19:21
  • 1
    @Gaius, there could be wanted features that would require another version to be made. :) – JB King Jul 08 '13 at 20:21
  • 1
    @DanPichelman: I can attest to the fact that the compiler I work with on a daily basis has several known and reported bugs which we work around in our code using conditional defines and even have tests to alert us when they have been solved in a newer compiler version. Some of these were indeed solved in newer versions of the compiler and the conditionally compiled workarounds and the tests have since been removed from our code base. Does that address your "None of the comments or answers so far address the likelihood of encountering a compiler bug."? – Marjan Venema Jul 08 '13 at 20:26
  • @Christian: Agreed, except that the probability isn't quite 100%. There are also cases where the language specification is ambiguous, and an apparent "bug" is the result of the compiler implementers' interpretation of the spec. (In most such cases, the best solution is to write simpler code that avoids the ambiguity.) – Keith Thompson Jul 08 '13 at 22:22
  • 2
    @Gaius Because version numbers aren't only bumped when fixing bugs but also when adding and removing features. In fact, under semantic versioning, the part of the version number you notice (major and minor part) don't change at all for bug fixes. You could fix a thousand bugs over a hundred releases and still be at v1.0. –  Jul 08 '13 at 22:37
  • 3
    You can have defects in compilers, operating systems, libraries, CPUs, microcode, memory, disk controllers and the initial program specifications. Add in bit-flips caused by occasional cosmic rays and we can see that life is hard. – David Plumpton Jul 09 '13 at 02:01
  • I've made compilers repeatably crash before. – Peter Taylor Jul 09 '13 at 07:08
  • @KeithThompson Well, 100% was rounded, obviously, but not very generously IMHO. And yeah, the one time I learned above rule of thumb the hard way was a C++ specification oddity that wasn't even ambiguous but still made no sense to me. Still doesn't. – Christian Jul 09 '13 at 10:21
  • See [Can compiler optimization introduce bugs?](http://stackoverflow.com/questions/2722302) – BlueRaja - Danny Pflughoeft Jul 09 '13 at 14:44
  • 4
    The C# specification is eight hundred pages long and has been continuously developed for over a decade by a large team. Do you really suppose that in that time there was not a single bug introduced? – Eric Lippert Jul 09 '13 at 15:46
  • Maybe this would be considered more on topic if posed as "Can compilers have bugs, and how can we (as users) deal with them?" – KChaloux Jul 10 '13 at 17:22

10 Answers10

101

In layman's words:

All programs can have bugs.

Compilers are programs.

Ergo, compilers can have bugs.

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
  • 55
    More worrisome: Debuggers are programs. Therefore, debuggers have bugs. – daniel gratzer Jul 08 '13 at 14:52
  • 19
    @jozefg: So how do you debug the debugger? Who watches the watchers? – FrustratedWithFormsDesigner Jul 08 '13 at 15:04
  • 16
    @FrustratedWithFormsDesigner The watcher watchers, duh. – Jimmy Hoffa Jul 08 '13 at 15:14
  • 2
    @JimmyHoffa Well if we're talking about computers, [the watchers just look in a mirror](http://en.wikipedia.org/wiki/Reflection_%28computer_programming%29). – Tacroy Jul 08 '13 at 15:47
  • 2
    The correct quote is all *non-trivial* programs have bugs. Most "Hello world" programs probably don't have bugs. – JoelFan Jul 08 '13 at 16:19
  • 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. – Tulains Córdova Jul 08 '13 at 16:43
  • 8
    "Hello world" programs can have bugs if its complied with a bugged compiler. – wtsang02 Jul 08 '13 at 17:50
  • 1
    @jozefg: Debuggers with bugs are not that worrisome. Proof: debugging tools are, by and large, buggy piles of crap with numerous limitations, and yet we are able to use them. A bad debugger won't introduce problems into your code; it's just unhelpful or misleading so that you waste time (or at least fail to reduce your time) in root causing a problem. – Kaz Jul 08 '13 at 19:05
  • 1
    @Kaz The worst that happens with most compiler bugs is you dump the assembly/bytecode/IL/whatever and look to see if it's doing something wrong. Usually you can even compare with another compiler to see if it's only your compiler Labor intensive but determinstic. A debugger bug you usually never suspect + debugging a debugger whilst trying to use the debugger to debug some piece of code you care about is **very** annoying – daniel gratzer Jul 08 '13 at 19:12
  • @jozefg Compiler bugs introduce problems into binary code that don't always show up in testing. The worst that actually happens is that the compiler bug is identified late, and it affects unknown amounts of code that have been shipped by unknown numbers of developers who use that compiler. – Kaz Jul 08 '13 at 19:25
  • 1
    @Kaz: I've had a very nasty encounter with a debugger bug. When single-stepping the debugger would permit an invalid value to be loaded into a segment register. The result was code that errantly stored a 32-bit value into a segment:offset pair would appear to work. This allowed a bug in the runtime library to slip through. – Loren Pechtel Jul 08 '13 at 20:55
  • C compilers are written in C. – Captain Kenpachi Jul 09 '13 at 07:58
  • @LorenPechtel If you test code by single stepping it, you will run into situations like this where the semantics differ under the debugger. Debuggers aren't really for confirming that the code is working; they are investigation tools. (At least, not debuggers for fragile assembler-like languages like C; the debugger-like interactive environments for higher level languages are a different story.) Remember, the debugger can tell you that `i = a[i++]` is working just fine! Or that a variable has a particular value, when it is in fact uninitialized and has a different one outside of the debugger. – Kaz Jul 10 '13 at 00:52
  • @Kaz: I didn't make the bug, I just had fits finding it. I had code that would fault most of the time and occasionally work, when I stepped through it it worked 100% of the time. I finally figured out the bug was the RTL storing real mode pointers in pointer type variables. – Loren Pechtel Jul 10 '13 at 01:06
50

Yes

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.

Community
  • 1
KChaloux
  • 5,773
  • 4
  • 35
  • 34
  • 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 Jul 09 '13 at 10:03
  • @Andy it looks like one of the moderators rejected it as something that should be a comment or separate answer. – KChaloux Jul 09 '13 at 12:51
  • Not just "yes", but "hell yes!" :-) – Hellion Jul 09 '13 at 14:45
  • C is both mature and actively developed. So is C++. So is Java. etc.. – djechlin Nov 10 '14 at 05:29
22

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.

Random42
  • 10,370
  • 10
  • 48
  • 65
8

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.

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
Joel
  • 1,169
  • 8
  • 12
  • 1
    There's also a [list of C++ fixes and breaking changes in Visual Studio 2013](http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx). – sourcenouveau Jul 08 '13 at 14:57
5

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.

Curt
  • 151
  • 3
  • 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. – David Plumpton Jul 09 '13 at 01:57
  • 1
    What was the software? C'mon :) – Rocklan Jul 09 '13 at 05:44
2

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.

Juha Laiho
  • 129
  • 1
1

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

JohnB
  • 1,231
  • 2
  • 8
  • 10
0

Yes.

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?

JNL
  • 904
  • 2
  • 8
  • 18
  • Your important question will then lead back to the [Halting problem](http://en.wikipedia.org/wiki/Halting_problem) – wtsang02 Jul 08 '13 at 17:57
0

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

Abhishek Kulkarni
  • 109
  • 2
-1

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.

Community
  • 1
Viktor Lova
  • 107
  • 3
  • 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. – jszpilewski Jul 09 '13 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 Jul 09 '13 at 15:12
  • @Andy, as I know, no one has knowed what problems this decision will cause. Why not bug? – Viktor Lova Jul 09 '13 at 16:08
  • @jszpilewski do you see a smile after that text? – Viktor Lova Jul 09 '13 at 16:09
  • Its not a bug because they designed for each a certain way. Yes its unexpected with lambdas in the mix, but it was a purposeful choice made by the language designers. They did change this in .net 4.5 though. Read more about it here http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx – Andy Jul 10 '13 at 01:05
  • @Andy: why when architects screwed up they just made some decision, but when coders screwed up - we got a bug? – Viktor Lova Jul 10 '13 at 01:13
  • @Andy, okay, let's look on a definition of bug from wiki: A software bug is an error, flaw, failure, or fault in a computer program or system that produces an incorrect or **unexpected** result, or causes it to **behave in unintended ways**. Most bugs arise from mistakes and errors made by people in either a program's source code or its design, ... . Now we can extrapolate definition of software bug to language specification bug. – Viktor Lova Jul 10 '13 at 01:14
  • @nsinreal If you don't want to believe what one of the C# compiler developers tells you, I really can't help you. Read the blog; Eric clearly says the defined the behavior in the C# specs. The fact that people didn't bother to check the specs is not relevant to whether or not the C# compiler met the specs or not. – Andy Jul 10 '13 at 18:49
  • @Andy: hey, please, read my words (in post and in this comment) carefully. Maybe you need to reread it two times. I didn't say that there is a bug in compiler, okay? I sayed that the language specification is defined so, that programmers on C# seems unexpected non-intuitive result from compiling. There are no bug in compiling process, there is a bug in language specification. – Viktor Lova Jul 10 '13 at 19:24
  • 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 Jul 10 '13 at 19:33
  • @Andy, I wroted "Even language specification can have a bug" and then showed 2 examples of bugs - one in python, one in php. Text about c# was **related** offtopic. \n Quote from wikipedia says only about *sofware* bugs, not about all kinds of bugs. So, what is problem in my answer? – Viktor Lova Jul 10 '13 at 19:50