Intel compiler bug?

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Intel compiler bug?

Post by bob »

wgarvin wrote:Oh, I just thought of another good compiler bug. Two of the compilers we currently use (from the same vendor) have a ridiculous parsing bug in them where sometimes they "forget" about an enum declaration and incorrectly report compile errors everywhere you try to use it. One of the compilers is near its end-of-life and so its unlikely the vendor will ever fix the bug.

The problem is deterministic, and will keep recurring if you keep feeding the same source code to the compiler. Our current workaround, I kid you not, is to insert a space after the keyword "enum" and before the name of the enum. So once or twice a week, a programmer will submit some random code and then our automated build will turn red because of this bug, and someone will have to edit the whitespace to turn it green again.

Yes its appalling that a stupid bug like that can make it through all of the testing that compiler vendors do and end up in the released product, but sometimes it happens anyway. At least this one just causes the build process to fail and doesn't cause incorrect codegen.

Once we also had a linker bug to contend with that we were never able to find a good workaround for; every 10 or 20 builds, one of them would randomly have some incorrect prologue/epilogue code transformation applied by the linker. If you ran the resulting executable and it happened to call the mangled function, it would crash with a weird but recognizable callstack. The only workaround was to make a trivial edit to the source code and recompile and relink. Fortunately, that one got fixed by the vendor.
You should have been around when "long long" hit the street. It seemed to work reasonably for add, subtract and such. But when I started to play with Cray Blitz on a vax running BSD unix, I needed a way to do 64 bit stuff. Tried floats but you could not use a float for things like hashing because there are illegal combinations of bits that the vax hardware would puke on (just like IEEE today, in fact). long long was brand new, and I started using it, and I spent a year off and on reporting bugs and providing fixes to the gcc guys. Had no idea there were so many ways to mangle 64 bit shifts, ands, exclusive ors, and particularly 64 bit comparisons. Not to mention passing them as arguments to functions and such. I remember fighting A & A - 1 for a LONG time. The optimizer was particularly nasty about breaking long long code trying to be too cute.