How did that bug pass testing? Isn't the first test of correctness that you generate the 3.5 million permutations of 1..10 and sort every single one correctly?
“It is never a compiler error”
51–60 of 280 posts
Re: “It is never a compiler error”
#52I work in embedded software, usually with compilers co-evolving with the hardware.
In 10 years, I've seen 3 compiler bugs. That's just enough to leave the door cracked open for "y'know, it could be a compiler bug..."
Re: “It is never a compiler error”
#53re: the fix for the off-by-one error
// but it should have been:
if (changes == 0) break;
// still stops on negative values
if (changes // first trap problems
if (changes Re: “It is never a compiler error”
#54Earlier quoted context omitted.
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…
Hu. Bubble Sort. And not only that; a buggy version! And if you believe sequential access is gonna save you from O()... you're so wrong its not even funny. Of course the curves will cross latter. But they will cross. Especially on a sort.
I'm not sure you've demonstrated anything here about the topic under discussion. You might like to try achieve a better result around here, people tend to appreciate it.
Re: “It is never a compiler error”
#55Way back in the day HP had just transitioned its HP-UX C++ compiler from its older, Cfront-based, C++ compiler to a native solution. I found (in released code, no less!) some fairly trivial template compositions (I forget exactly, but it was something like a map of some object to a vector of something else) that crashed the compiler.
Re: “It is never a compiler error”
#56Sadly, 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.
Re: “It is never a compiler error”
#57When 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 all code has bugs.
Re: “It is never a compiler error”
#58I don't understand the env in which this happened, because cracking open my console, I get
> [5, 4, 5, 1].sort().join('')
> "1455"
Re: “It is never a compiler error”
#59I don't understand the env in which this happened, because cracking open my console, I get > [5, 4, 5, 1].sort().join('') > "1455"
They are using a sandboxed javascript interpreter.
https://github.com/code-dot-org/JS-Interpreter
See the pull request here https://github.com/code-dot-org/JS-Interpreter/pull/23
Re: “It is never a compiler error”
#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 need a language that we can't use safely without "understanding of the way arguments to unprototyped functions are automatically promoted"? IMHO the number-one principle to be followed in every sane language design is the "principle of least surprise" (POLA). If the language can surprise you easily and lets you write weird code that is going to work a way different from what one will probably assume intuitively - that's a language made wrong.