Re: Intel C++ bug reports?
On 09/04/12 21:25, Martin Sebor wrote: On 09/04/2012 07:02 PM, Liviu Nicoara wrote: 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: 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. FWIW, I like the current implementation more. It seems to me that, by using a bitwise logical shift of the corresponding unsigned integer, followed by a conversion to the signed integer, we'd make an assumption about the representation of signed integers. But a shifting implementation should be relatively easy to add. Liviu
Re: Intel C++ bug reports?
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
RE: Intel C++ bug reports?
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, >>> >>> >>> >> 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?
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. Thanks. Liviu
Re: Intel C++ bug reports?
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.
Martin
$ uname -a; icpc -v; cat t.cpp; icpc t.cpp&& ./a.out
Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD
Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux
icpc version 12.1.5 (gcc version 4.5.2 compatibility)
#include
volatile int zero = 0;
volatile int one = zero + 1;
volatile int two = one + 1;
template< typename T>
T test ()
{
T max = T (one);
// Find largest in which multiplied by two results in a
// negative value
for (; T (max * two)> max; max *= two) ;
//
// Perform a binary search variant for the maximum
//
T tmp = max / (two + two);
for (; tmp;) {
if (T (max + tmp)< max) { //<- fail
if (tmp> T (two))
tmp /= two;
else if (max< T (max + one))
tmp = one;
else
break;
}
else
max += tmp;
}
return max;
}
int main ()
{
printf ("INT_MAX : %x\n", test< int> ());
return 0;
}
^C
$
which runs just fine with gcc:
$ g++ t.cpp&& ./a.out
INT_MAX : 7fff
Thanks!
Liviu
Re: Intel C++ bug reports?
On 09/ 5/12 08:02 AM, Liviu Nicoara wrote: Hi guys, Does any of you know how to go about submitting an Intel compiler bug without a premier support account? Try posting on the forums - If you include a reduced test with no STL dep it will help them.
Intel C++ bug reports?
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:
$ uname -a; icpc -v; cat t.cpp; icpc t.cpp && ./a.out
Linux behemoth 2.6.37.6 #3 SMP Sat Apr 9 22:49:32 CDT 2011 x86_64 AMD
Opteron(tm) Processor 6134 AuthenticAMD GNU/Linux
icpc version 12.1.5 (gcc version 4.5.2 compatibility)
#include
volatile int zero = 0;
volatile int one = zero + 1;
volatile int two = one + 1;
template< typename T >
T test ()
{
T max = T (one);
// Find largest in which multiplied by two results in a
// negative value
for (; T (max * two) > max; max *= two) ;
//
// Perform a binary search variant for the maximum
//
T tmp = max / (two + two);
for (; tmp;) {
if (T (max + tmp) < max) { // <- fail
if (tmp > T (two))
tmp /= two;
else if (max < T (max + one))
tmp = one;
else
break;
}
else
max += tmp;
}
return max;
}
int main ()
{
printf ("INT_MAX : %x\n", test< int > ());
return 0;
}
^C
$
which runs just fine with gcc:
$ g++ t.cpp && ./a.out
INT_MAX : 7fff
Thanks!
Liviu
