Intel compiler bug?

[xmas79]

The bug has been confirmed by Intel support and passed to engineering (reproducible in XE 15 as well).

Unbelievable...

[wgarvin]

Quite expensive.... $699 for a single developer "base" license...

Yes, considering it's buggy

Pretty much all optimizing compilers are a little bit buggy, even extremely-well-tested ones. A modern optimizing compiler has a LOT of complex parts that can interact with each other in really subtle ways.
http://blog.regehr.org/archives/1061
http://blog.regehr.org/archives/1036
http://blog.regehr.org/archives/1170

...That said, most programmers don't really understand undefined behavior and so it happens a lot that they write something which has no defined meaning according to the language and then they're surprised when the compiler does something weird to it. So always check your code carefully for UB before blaming the compiler!

[mar]

...That said, most programmers don't really understand undefined behavior and so it happens a lot that they write something which has no defined meaning according to the language and then they're surprised when the compiler does something weird to it. So always check your code carefully for UB before blaming the compiler!

I agree, but this is now a confirmed high priority defect that exists since late XE 11 and will be fixed in some of the upcoming updates.
If you pay $700 for a compiler (I did), you don't expect it to break some trivial multiply with 256; OTOH bugs just happen.
At least they could have given me a discount or something

[xmas79]

At least they could have given me a discount or something

At least they could have given ALL OF US a discount or something

[mar]

At least they could have given ALL OF US a discount or something

Well I found a bug for them But to be fair, Intel support acted quickly and professionally and it only took 2 days to pass it from support => developers.
Anyway, bug found => will be fixed => case closed

[mar]

So always check your code carefully for UB

Speaking of UB, let's talk about implementation defined behavior (which is not the same thing, sure),
I intentionally rely on IDB in some cases (where I would otherwise sustain a big performance hit - namely >> on signed integers),
I also break strict aliasing intentionally sometimes (like fetching binary rep of float as uint to extract sign bit, this gave me a really nice speedup extracting support point of AABB wrt normal).
Also I don't zero-init some classes (2d/3d vectors etc.), which gave a speedup as well.
So if one knows what he's doing... it may be a net win actually (willing to take the risk that it might break in the future
I don't want to code around the specs just to satisfy it, I simply have a goal that I want to achieve (why waste performance and time).
In fact I would very much prefer to see some weird UB/IDB/... gone instead of something super useful like being able to overload . operator or define custom literals
I have a feeling that "the standard guys" are holding a troll party.
Actually, speaking of large projects, I bet there's not a single one that is fully portable according to specs

[Rein Halbersma]

I intentionally rely on IDB in some cases (where I would otherwise sustain a big performance hit - namely >> on signed integers)

Can you give an example where it would not be possible to rewrite the >> on unsigned integers without losing performance? IMHO, shifting on signed integers is a code smell. E.g. your code example that started this thread had signed int parameters that can be completely replaced with unsigned integers.

[mar]

Can you give an example where it would not be possible to rewrite the >> on unsigned integers without losing performance? IMHO, shifting on signed integers is a code smell.

Sure, if you're mixing samples and doing volume ramping. You can't use unsigned samples in that case (without performance hit).

E.g. your code example that started this thread had signed int parameters that can be completely replaced with unsigned integers.

As I said this was due to simplification of the original code, I needed something reproducible quickly so I didn't bother.

[wgarvin]

I agree, but this is now a confirmed high priority defect that exists since late XE 11 and will be fixed in some of the upcoming updates.
If you pay $700 for a compiler (I did), you don't expect it to break some trivial multiply with 256; OTOH bugs just happen.
At least they could have given me a discount or something Wink

Compiler bugs are rare and weird, but they happen. I reported one to Microsoft a few years ago where some mishandling of a loop condition resulting in a weird-but-legal bounded loop being miscompiled instead into an infinite loop. It turned out to be a loop induction variable bug in their front-end that had been there for years, but apparently nobody had run into it until then.

Some compiler features are buggier than others; volatiles used to be pretty unreliable for example. We've had to avoid certain intrinsics on some of our platforms/compilers because they caused bad codegen (such as causing unrelated stores to be incorrectly discarded from the output). I remember a particularly bad bug involving LTCG and incorrect constant propagation, that caused a slow but continuous memory leak in one of the games I worked on. We only started testing of the LTCG version near the end, so we didn't notice until it was dangerously close to shipping, but fortunately the cause was discovered and worked around. The code pattern that was triggering the bug was a frighteningly simple and normal-looking bit of reference counting code. The optimizer mistakenly thought an expression was a compile-time constant and generated some totally wrong code in which the "free when the refcount reaches zero" code could never be executed.

Regehr's CSmith tool generates random C programs and CReduce then automatically down-sizes them into smaller programs that still trigger the bug; with this pair of tools he has found literally hundreds of compiler bugs most of which can be triggered by trivial little 10- or 20-line programs.

Can you give an example where it would not be possible to rewrite the >> on unsigned integers without losing performance? IMHO, shifting on signed integers is a code smell.

Sure, if you're mixing samples and doing volume ramping. You can't use unsigned samples in that case (without performance hit).

I think right-shifting of signed ints by 0..N-1 bits should be completely safe (and implementation-defined, but all 2's complement CPUs will do the same thing). Its left-shifting you have to be wary of, because shifting a 1 into or through the sign bit is undefined.


UB is bad. We've talked about it here before; the scary thing is that there's over 200 kinds of UB and some of them are weird ones that most programmers aren't too familiar with. For example, with dangling pointers, its not just dereferencing them but any use of the pointer value that is undefined, so even code comparing two pointers to the same block of freed memory can get optimized into "if (false)" and discarded. UB really can make demons fly out of your nose.

[wgarvin]

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.