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

61–70 of 280 posts

Re: “It is never a compiler error”

#61

Post by MichaelGG »

topspin wrote: post #39
empath75 wrote: post #28

Earlier quoted context omitted.

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

Yeah working on FreeSWITCH, upgrading to VS2015 and we encountered an issue with a long series of else branches. Ended up having to split and nest for the code to compile.

Re: “It is never a compiler error”

#63

Post by dvtv75 »

topspin wrote: post #39
empath75 wrote: post #28

Earlier quoted context omitted.

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

When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there.

Eventually, someone (Natalie) moved the comment below the assignment, and it worked normally. I tried putting it back above, and it wouldn't compile. Can't remember what happened if I left the moved comment in place and put another above the assignment. I found two like that - one in CodeWarrior, one in Turbo Pascal a few years before that simply returned "error 0: no error."

It wasn't anything complicated in either case, just very basic stuff.

Re: “It is never a compiler error”

#64

Post by throwaway613834 »

dvtv75 wrote: post #63
topspin wrote: post #39

Earlier quoted context omitted.

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

When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there. Eventually, someone (Natalie) moved the comment below the assignment, and it worked nor…

Any chance the line endings were different and that was somehow messing it up?

Re: “It is never a compiler error”

#65

Post by davidbanham »

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 in our wrapper that was there to emulate legacy behaviour of the old ObjC app it replaced.

We assumed the leak was somewhere in our code or the other vendor's code. We spent _months_ trying to figure this thing out. I spent countless hours looking at heap dumps. Going over every bit of dumb code to try and figure out what was wrong. This was a big undertaking with a lot on the line from our client.

Then one day we upgraded the version of node-webkit. It happened to include a newer build of webkit. The bug _vanished_ on the OSX and Windows builds. That was our big break. All of a sudden the possibility of a compiler bug was on the table.

We ended up tracking it to a bug in webkit's implementation of (iirc) the html5 filesystem API. Nobody used it much and as far as I can tell, we were the only ones using it as heavily as we were.

Happy days for OSX and Windows, but the iOS build was still horrible because iOS was using a webkit build from before the patch.

We begged and pleaded with Apple to give us some indication of whether or when the build would be updated. wkwebview came and it was still busted.

The project ended up being closed down, in no small part due to the iOS bugs. I moved on. I have no idea to this day whether or not the iOS build has been updated or not.

Re: “It is never a compiler error”

#66

Post by wyldfire »

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.

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

Re: “It is never a compiler error”

#67

Post by frivoal »

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…

Having to use a specific point release of the compiler to work does not necessarily means later version have a bug. It could also mean that the program is (accidentally) depending on implementation details that are not guaranteed by the language, and that the compiler is supposed to be free to change behavior about. For languages like C with a significant amount of undefined behavior, that's actually quite likely.

Re: “It is never a compiler error”

#68

Post by revelation »

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.

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

Re: “It is never a compiler error”

#69

Post by nv-vn »

dvtv75 wrote: post #63
topspin wrote: post #39

Earlier quoted context omitted.

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

When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there. Eventually, someone (Natalie) moved the comment below the assignment, and it worked nor…

Something similar happened to me a while back in Mono/C#. I think it was the order of assignments for an unused variable changed the results of the code. Something like:

    int x = 0;
    int y = 2;
    DoSomething(); // Didn't run with x before y
I can't recall if I ever reported it or bothered looking into it, but a friend ran into a similar issue around the same time and it was really confusing, but it was resolved by changing some configuration (different compiler version or flags I think).

Only other time I bumped into it was in Idris, which is to be expected frankly.

Re: “It is never a compiler error”

#70

Post by EpicEng »

I fixed a bug (random crash) about eight years ago now caused by the Intel compiler failing to properly copy a function parameter into a register. At some point I just gave up looking at the code and took a peak at the disassembly. There it was.

So yeah, it's sometimes a compiler error.

Post reply on HN