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

“It is never a compiler error”

blog.plover.com

Post reply on HN
Print view View original

31–40 of 280 posts

Re: “It is never a compiler error”

#31

Post by mehrdada »

Twisol wrote: post #26
mehrdada wrote: post #22

Well, we've found quite a bunch: https://mehrdad.afshari.me/publications/compiler-validation-...

I immediately thought of this work when I saw the title. Of course, you're actively and effectively hunting down bugs, not accidentally running into them while doing other things ;)

Yes, but for example I remember at least one anecdote where one of our bugs we encountered was closed as a bug that manifested itself as a crashing bug in x264 or ffmpeg (I forget which) and ours was closed as a duplicate, so people do actually encounter bugs.

Re: “It is never a compiler error”

#32

Post by Lerc »

The only error I found where the code compiled but was wrong was from it assuming a particular symmetry in the instruction set. It tried to use an addressing mode on an instruction that didn't support it and consequently output two completely different instructions.

Errors in the run-time library and errors that crash the compiler are much more common. While many eyes cover a lot of search space. The space they have to cover has grown immensely.

If you step off the trodden path you can find problems much more often. Just recently I encountered a function in a run-time library that freed the amount of memory the alloc asked for instead of the amount of memory the alloc function actually returned (Sometimes it returned slightly more if the remaining space was not enough to hold a free-memory structure).

It would not surprise me if the population using that particular compiler/platform combination numbered less than a thousand.

Re: “It is never a compiler error”

#33

Post by philipkglass »

I have worked in a domain where "it is often a compiler error" -- scientific simulation. In particular, Intel's C and Fortran compilers generally produce the fastest binaries on Intel hardware but they also seemed to break builds a lot. The answer to "the validation suite no longer passes" was often "use this specific point release of the compiler."

I wasn't personally developing the core simulation software itself at the time, just building it from source and writing extensions. I don't know if these frequent breakages were actually outright compiler bugs or just relying on conventions that weren't guaranteed by language specs. But I do know that switching to one particular blessed compiler revision was often the fastest way to pass validation and move on to your actual research problems.

Re: “It is never a compiler error”

#34

Post by maccard »

dredmorbius wrote: post #5

In over a quarter century of programming, I've twice found interpreter errors. Once a function performed the inverse of the documented behaviour (returning "true" for "false" and vice versa) in a proprietary system, the second was a gawk bug of some description I don't recall but proved to be an actual bug. The other bugs were all mine.

I’ve been writing c++ for about 9 years now, and I’ve hit plenty of errors in the compiler, some even with perfectly valid code.

I still always blame my own code first though

Re: “It is never a compiler error”

#35

Post by pjungwir »

Back in 2010 I wanted to try out Scala. I fired up the REPL and did this:

    scala> 1+2
    res0: Int = 12
Here is a blog post I wrote about it at the time: https://illuminatedcomputing.com/posts/2010/11/no-luck-tryin...

I was running under Cygwin and the issue was something about the Java-based readline library.

I filed a ticket (linked in my blog post but the link is broken now), but the maintainers' response was something like "Yeah right. Closed."

You'd think compiler bugs would be more obscure than 1+2. :-)

Re: “It is never a compiler error”

#36

Post by goialoq »

pjungwir wrote: post #35

Back in 2010 I wanted to try out Scala. I fired up the REPL and did this: scala> 1+2 res0: Int = 12 Here is a blog post I wrote about it at the time: https://illuminatedcomputing.com/posts/2010/11/no-luck-tryin... I was running under Cygwin and the issue was something about the Java-based readline library. I filed a ticket (linked in my blog post but the link is broken now), but the maintainers' response was somethin…

What's old is new again:

https://www.google.com/search?q=ios+1+2+3

Re: “It is never a compiler error”

#37

Post by scraft »

I have hit a number of C/C++ compiler bugs in GCC, MS VC, Code Warrior and various in other languages (for example shader compilers). I agree it is the sort of the last thing you blame, but at the same point, sometimes it really is, so I get a couple of sanity checks from skilled friends or colleagues, making a tiny repro, submit and move on!

Re: “It is never a compiler error”

#38

Post by mgraczyk »

pjungwir wrote: post #35

Back in 2010 I wanted to try out Scala. I fired up the REPL and did this: scala> 1+2 res0: Int = 12 Here is a blog post I wrote about it at the time: https://illuminatedcomputing.com/posts/2010/11/no-luck-tryin... I was running under Cygwin and the issue was something about the Java-based readline library. I filed a ticket (linked in my blog post but the link is broken now), but the maintainers' response was somethin…

The issue is now on github: https://github.com/scala/bug/issues/4009

Re: “It is never a compiler error”

#39

Post by topspin »

empath75 wrote: post #28
cperciva wrote: post #18

Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, especially when (as tends to be the case with LLVM) they are caused by assertions failing -- but I've also tripped over compiler hangs (there's a variable in the tarsnap code with an utterly bogus volatile specifier in order to avoid the problematic optimization on…

If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. For 99% of programmers, the chances that you have discovered one is small.

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.

Re: “It is never a compiler error”

#40

Post by oldandtired »

There are more compiler bugs than many ever think. From mainframe COBOL compilers to gcc, I have encountered bugs in programs that were a result of what the compiler did.

The original source code did nothing special - it was simple code and due to specific optimisations that the compiler performed, inexplicable seemingly random errors would arise. One would have to constrain the optimisations the compiler would do to get the code to execute correctly.

No compiler is bug free. The bugs can manifest in strange ways and sometimes they will manifest only on specific kinds of data (edge case data).

Certainly there are many programs that are written incorrectly and give rise to apparently inexplicable errors that are due to misunderstood language features or specified compiler limits.

However, there are also many programs that do not have such source code errors that end up being rewritten in some way to avoid compiler based errors.

The worst I have seen is when dummy statements have to be put in to the source code in order to get the program to work correctly. I have seen compilers change the precision of numbers from one version to the next and you have to add additional code to restrict those numbers back to the specified range. I have seen compilers allocate multiple i/o buffers as an optimisation that causes a program to fail when a single i/o buffer allocation works fine - one has to turn off the optimisation - no documentation available as to how the compiler generated code uses those buffers.

All I can say is that it takes a fair amount of investigation to determine what kind of bug it is when it is subtle and randomly occurring. It can be everything from errors in the source to errors in the libraries to errors in code generation to errors in the o/s (including driver errors or memory errors).

Anyone who blanket says the compiler is not to blame is living in a rose coloured glasses world. Compilers are complex programs and the source code for them can be just as wrong as for any other program. The code generated for compilers can be just as bug ridden as any other program.

Post reply on HN