RE: Intel C++ bug reports?

2012-09-05 Thread Travis Vitek

On 09/05/12 04:20, Liviu Nicoara wrote:
 On 09/04/12 21:25, Martin Sebor wrote:
 On 09/04/2012 07:02 PM, Liviu Nicoara wrote:
 Hi guys,

 snip

 Looking at the test below, though, it depends on undefined behavior
 (signed overflow) so there's no compiler bug. Making max volatile
 fools icc just enough to produce the expected output (while still
 relying on undefined behavior). It would be good to clean it up,
 though. I think computing UINT_MAX instead and shifting it right
 by the number of sign bits (i.e., 1) should work.
 
 I _know_ it's undefined behavior. :) My case is that Intel is also the
 only compiler failing this test. On that grounds alone they should look
 at it -- I know the gcc guys do when it comes to their compiler. Let
 them shoot it down if they so wish.

Rogue Wave filed an issue with Intel on 2011/04/25 (issue #628095). They shot 
it down.

Travis


Re: Intel C++ bug reports?

2012-09-05 Thread Martin Sebor

On 09/05/2012 05:20 AM, Liviu Nicoara wrote:

On 09/04/12 21:25, Martin Sebor wrote:

On 09/04/2012 07:02 PM, Liviu Nicoara wrote:

Hi guys,

Does any of you know how to go about submitting an Intel compiler bug
without a premier support account?

While configuring the library on my x86_64 machine, I ran into what
appears to be a code generation compiler bug which affects LIMITS.cpp
test -- the test cycles ad infinitum because of the incorrect test
marked below:


I don't know if there's a way to submit it outside Premier but I
have an account and can submit bugs for us.

Looking at the test below, though, it depends on undefined behavior
(signed overflow) so there's no compiler bug. Making max volatile
fools icc just enough to produce the expected output (while still
relying on undefined behavior). It would be good to clean it up,
though. I think computing UINT_MAX instead and shifting it right
by the number of sign bits (i.e., 1) should work.


I _know_ it's undefined behavior. :) My case is that Intel is also the
only compiler failing this test. On that grounds alone they should look
at it -- I know the gcc guys do when it comes to their compiler. Let
them shoot it down if they so wish.


GCC also implements a similar optimization (-fstrict-overflow).
IIRC, we've already tweaked the test to get around it at least
once (by declaring zero, one and two volatile). GCC happens to
miss this case, but ICC doesn't and optimizes the test away,
turning the whole for statement into an infinite loop.

Martin

PS Here's a nice example of a GCC bug filed for the same type
of a problem as we have here:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36862



Thanks.

Liviu