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

71–80 of 280 posts

Re: “It is never a compiler error”

#71

Post by gpderetta »

philipkglass wrote: post #33

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 a…

IIRC the intel compiler has the equivalent of gcc -ffast-math on by default, i.e. it explicitly breaks some the C and IEEE 754 floating point specs in some places in exchange for performance.

Re: “It is never a compiler error”

#72

Post by eridius »

davidbanham wrote: post #65

I was lead on a project that was making heavy use of the HTML5 filesystem API. We were transiting multiple GB through the API in a single session. The program had a memory leak. It was about the same whether it was deployed through Cordova on iOS or node-webkit on OSX or Windows. There was a _lot_ of code in this thing. A lot of code within the content (which was written by another vendor) and a whole bunch of code i…

This comment has me rather confused. iOS updates webkit at the same time that macOS does; namely, when releasing a major OS update. And they both use the same webkit too. It should not be possible for a webkit bug to be fixed in macOS but still be unfixed in iOS after a major version update (and since you say "wkwebview came" this means there was a major version update).

Re: “It is never a compiler error”

#73

Post by gpderetta »

revelation wrote: post #68
wyldfire wrote: post #66

Earlier quoted context omitted.

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

UBSan catches undefined behavior at runtime - so by definition everything it reports was not used by Clang to fold your program to a constant.

When the sanitizer is on, the optimizer (modulo bugs of course) does not remove the checks.

Re: “It is never a compiler error”

#74

Post by Jach »

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…

You're misidentifying the attitude. The problem is that Bubble Sort is a terrible algorithm, there's no reason not to use Insertion Sort or better instead except for some reason CS programs still inflict BS on students so that's what they remember when they just need to sort something.

http://warp.povusers.org/grrr/bubblesort_eng.html

http://warp.povusers.org/grrr/bubblesort_misconceptions.html (Bubble sort is not great when your data is almost sorted. Insertion sort is, though.)

Re: “It is never a compiler error”

#75

Post by inimino »

harry8 wrote: post #15
mottomotto wrote: post #9

Earlier quoted context omitted.

It is silly to kick JavaScript in this example because the bug* is in the library of a custom JavaScript interpreter not a common runtime. * https://github.com/code-dot-org/JS-Interpreter/pull/23

We should consider separate bugs in the language spec from the implementation. In JS it's insane not to K&R brace as it will try to infer missing semi-colon terminators in your code, silently, to your doom. That's surprising if you have the misfortune. It's a massive bug in the language spec but the implementation of the JS interpreter is 100% correct as it kicks you, hard. Parent comment makes sense to me as a gener…

K&R braces have approximately nothing to do with semicolon insertion...

Re: “It is never a compiler error”

#76

Post by kbenson »

mdhughes wrote: post #57

When using a new version of a compiler, and existing code stops working, it is often a compiler error. When different compilers give different results, it is often a compiler error. I've hit dozens or hundreds of these, across many languages for decades. It's not the first thing to check, but once you verify the code is logically correct, that can be the only conclusion. Compilers aren't excessively complex code, but…

> When using a new version of a compiler, and existing code stops working, it is often a compiler error. When different compilers give different results, it is often a compiler error.

To be fair, sometimes that's because the compiler became more strict and your code had an error that wasn't being caught. Sometimes it's the compiler taking a more liberal stance on what "undefined behavior" is for performance reasons. In both cases, that would still a programmer error (and I think those are likely the more common case than an actual compiler error).

Re: “It is never a compiler error”

#77

Post by aalleavitch »

qwerty456127 wrote: post #60

"The compiler did not have a bug. The compiler never had a bug. The bug was always in the programmer's code and usually in their understanding of the language... It was caused by a misunderstanding of the way arguments to unprototyped functions were automatically promoted..." - I'd say the bug is neither in the compiler nor in their understanding of the language but in the language itself then. Why on Earth do we nee…

Some people seem to believe that you shouldn't use a language unless you're capable of writing the language yourself.

Re: “It is never a compiler error”

#78

Post by islemaster »

flukus wrote: post #25
blt wrote: post #2

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

For me it's that they aren't testing it. This sort of functionality is so trivial to write unit tests for, so simple that it's the fastest and easiest way to write and debug the sort method. It'd make me question the stability of the rest of their product too.

Actually, that's a fascinating part of the story. We run the entire test262 ECMAScript Conformance Suite (https://github.com/tc39/test262) against our JS-Interpreter fork. We don't pass the whole thing yet, but it ensures we only ratchet toward conformance to the language spec.

We checked, and this particular bug was not caught by the test262 suite - the broken sort worked for enough cases to slip past the Array.prototype.sort tests there. We've added a regression test for this issue in the layer that consumes the interpreter, but I've thought about proposing more aggressive validation of sort behavior to the test262 project.

It was a great reminder to me that while tests may be necessary for quality, they are not always sufficient!

Brad, Code.org Engineering

Re: “It is never a compiler error”

#79

Post by kllrnohj »

revelation wrote: post #56
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…

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.

> when I can narrow it down to a single offending function, that gets optnone slapped on it and done

If you're able to narrow it down that far why not then fix your bug?

Re: “It is never a compiler error”

#80

Post by CobrastanJorji »

When I was just getting into the industry, I was offered a job from a team at IBM, working on some OS or other whose name I forgot. I was chatting with the head developer about the workflow. He told me that, as the OS was written in a custom programming language, and the OS was the only program ever written in this programming languages, they found that roughly 50% of the bugs they encountered were in the OS code, and roughly 50% were in the compiler for the OS code.

I very politely finished the interview and then ran away as fast as I could and never looked back. I did not need that shit in my life. The world where it's always my fault is a better place.

Post reply on HN