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

101–110 of 280 posts

Re: “It is never a compiler error”

#101

Post by hyperpallium »

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…

Yay, I've found a compiler error (and a hardware error too). Only one each, though, and it took me a while to be sure.

Re: “It is never a compiler error”

#102

Post by deathanatos »

outworlder wrote: post #23

This goes for other things as well, not just compilers. As of this moment I am begrudgingly creating a support ticket with AWS for an issue which I am 99.99999999% confident is in our VM and has nothing to do with AWS itself. For some reason, "AWS issues" is one of the first things raised, even though we are unlikely to be hitting AWS edge cases, not being Netflix-scale. Honorable mention: "Kernel issue"

AWS is nowhere near as reliable as a compiler. We've seen things ranging from "S3 intermittently takes 60 or 120 seconds (or some multiple thereof)" (but apparently only for my buckets…) to spatial indexes in Aurora just flat out didn't work when they were released, to S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404), to ELBs corrupting the HTTP connection depending on packet timings.

That's aside from the more common issues of "this VM is just going to bite the dust", which is something I feel is just inevitable.

The kernel is more reliable, IMO (except when it comes to the Thinkpad TrackPoint drivers).

Re: “It is never a compiler error”

#103

Post by yaur »

adekok wrote: post #89

I ran into a GCC bug years ago. (1999-2000). It would put "static" variables into the "text" section of ELF binaries. i.e. into the read-only portion of the binary. The result, of course, was that writing to the variables caused a core dump. So yes, 99% of the time, stupid programmer errors are stupid programmer errors. But compilers do have bugs. e.g. https://github.com/practicalswift/swift-compiler-crashes

Im going to guess that was 2.96

https://www.gnu.org/software/gcc/gcc-2.96.html

Re: “It is never a compiler error”

#104

Post by ridiculous_fish »

Three compiler codegen bug war stories:

1. libdivide found a gcc 4.8 vectorizer bug in high multiplies. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61108

2. Circa 2001, I decided to learn Java. My first-ever Java program performed a right shift by -1 (for some reason I can't recall but was probably really stupid). The spec requires this to be equivalent to >>31, but the compiler wrongly optimized it to >>0. My confused post can probably still be found in comp.lang.java.help.

3. I wrote a Python script that generated a large set of test cases for an FFI (NSInvocation). The test crashed inexplicably on PowerPC64 with a nonsense backtrace. Turns out the PPC64 jump instruction has a 24-bit literal offset, and my functions were so large they overflowed it. That got fixed (also in gcc).

Re: “It is never a compiler error”

#105

Post by xelxebar »

The article mentions another Coding Horror one at the bottom [0]. I found this tidbit from there interesting:

"In Code Complete, Steve McConnell cited two studies that proved it:

"A pair of studies performed [in 1973 and 1984] found that, of total errors reported, roughly 95% are caused by programmers, 2% by systems software (the compiler and the operating system), 2% by some other software, and 1% by the hardware. Systems software and development tools are used by many more people today than they were in the 1970s and 1980s, and so my best guess is that, today, an even higher percentage of errors are the programmers' fault."

I'd really like to learn how to track down hardware bugs, or mess with things like Christopher Domas does.

[0] https://blog.codinghorror.com/the-first-rule-of-programming-...

Re: “It is never a compiler error”

#107

Post by openasocket »

deathanatos wrote: post #102
outworlder wrote: post #23

This goes for other things as well, not just compilers. As of this moment I am begrudgingly creating a support ticket with AWS for an issue which I am 99.99999999% confident is in our VM and has nothing to do with AWS itself. For some reason, "AWS issues" is one of the first things raised, even though we are unlikely to be hitting AWS edge cases, not being Netflix-scale. Honorable mention: "Kernel issue"

AWS is nowhere near as reliable as a compiler. We've seen things ranging from "S3 intermittently takes 60 or 120 seconds (or some multiple thereof)" (but apparently only for my buckets…) to spatial indexes in Aurora just flat out didn't work when they were released, to S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404), to ELBs corrupting the HTTP…

> S3 acknowledges writes prior to them being available to be read (causing a reader who picks up the item to receive a 404)

That's exactly documented behavior: http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction....

Re: “It is never a compiler error”

#108

Post by CountHackulus »

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

Re: “It is never a compiler error”

#109

Post by openasocket »

harry8 wrote: post #24
blt wrote: post #2

I'm more shocked that bubble sort is used in production somewhere...

I think we need to get away from this attitude, that I used to hold, that O() is everything. It isn't. It isn't even close. We should instead wonder why an algorithm was chosen without regard for the nature of the data on which it will be applied. For sorting O(n lg n) only makes sense as a selection criteria if you have absolutely no idea about what data is being sorted. Why is that? If the answer is you just don't…

> Others have pointed out that bubble sort is great when your data is already mostly sorted

It really isn't, compared to insertion sort. https://users.cs.duke.edu/~ola/papers/bubble.pdf shows insertion sort performs 5x better. I also like Knuth's Quote in TAOCP: "[A]lthough the techniques used in the calculations [to analyze the bubble sort] are instructive, the results are disappointing since they tell us that the bubble sort isn't really very good at all. Compared to straight insertion […], bubble sorting requires a more complicated program and takes about twice as long!"

> running sequentially through contiguous memory is something computers are just great at doing due to memory caching and prefetching

Name one sorting algorithm that doesn't involve purely running sequentially through contiguous memory.

Re: “It is never a compiler error”

#110

Post by ajross »

wyldfire wrote: post #66
revelation wrote: post #56

Earlier quoted context omitted.

clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approach for when something breaks in clang but works in gcc is to disable optimization, and when I can narrow it down to a single offending function, that gets optnone slapped on it and done.

> reckless ... is in the eye of the beholder. They exploit every corner of undefined behavior to the benefit of performance. Indeed other compilers might be "safer." Keep in mind that they also provide you with UBSan to help you detect when you're doing it wrong.

That argument would make more sense if they actually were faster, which they often aren't. Last I checked (and I don't keep up with this, to be fair) they still lagged gcc on most macrobenchmarks on x86.
Post reply on HN