Intel® C++ Compiler
Community support and assistance for creating C++ code that runs on platforms based on Intel® processors.

malcompilure?

oiskuu
Beginner
458 Views
/*
* test with icc-11.1.069 on intel64
*/

#include

#pragma auto_inline off

int comparative_truth(char *str, int a, int b)
{
int i;

if ((unsigned)a > (unsigned)b)
printf("(unsigned)%#x > (unsigned)%#x\\\\n", (unsigned)a, (unsigned)b);

for (i = 0; str && i < a; i++)
b += str;

return b;
}


int main(int argc, char **argv)
{
int n = 1;
comparative_truth("", n, -n);
}

0 Kudos
9 Replies
TimP
Honored Contributor III
458 Views
Is this what you dislike compilers to say?

oiskuu.c(11): error #12192: unreachable statement
oiskuu.c(13): error #12254: Buffer overflow: index is outside the bounds for arr
ay "" which is passed as actual argument 1 to "comparative_truth" at (file:oisku
u.c line:24); array "" of size (0:0) is indexed by value 1

oiskuu.c: In function `main':
oiskuu.c:25: warning: control reaches end of non-void function

I don't know any compiler which suppresses syntax checking on account of your pragma.
0 Kudos
oiskuu
Beginner
458 Views
I'm not sure how you've reached such result. I've added the code as an attachment, just in case.

Both gcc, icc compile that source on my box, with differing results. The icc compiled program
should output this following line:

(unsigned)0x1 > (unsigned)0xffffffff


ps. the character string "" has size no less than 1

0 Kudos
TimP
Honored Contributor III
458 Views
I get the same result (no output) with both gcc and icc. I suppose one could argue you have enough undefined behavior to get any result you choose. I don't see how you can argue about the result of the comparison, but I'll avoid further discussion of that.
0 Kudos
oiskuu
Beginner
458 Views
Tim, please do point out the cause of undefined behaviour. You can omit the #pragma and pass -inline-level=1
(or -O1) as flags, and you may add return to main(), those should not change the outcome. After that, it looks like a strictly conforming program to me, but maybe I'm just not seeing something??

Edit: make sure you test it on x86_64, on x86 it won't trigger.
0 Kudos
TimP
Honored Contributor III
458 Views
Yes, this is strange. The 64-bit compiler appears to be using, in effect, (long int) where you have (unsigned), when optimization is on. So it is converting to 64-bit signed integers, rather than observing (unsigned), while (unsigned long int) works as you apparently expect.
0 Kudos
Dale_S_Intel
Employee
458 Views
I'll look into it and see if we're doing something wrong. To be clear, what you're concerned about is the comparison of the two ints (a & b) that are cast to be unsigned, right? The stuff about inlining, opts and string lengths doesn't really pertain to that issue, correct? Let me know if I've missed something, in the meantime I'll try to figure out what's going on and whether it's a bug or a feature :-)

Thanks!

Dale
0 Kudos
Dale_S_Intel
Employee
458 Views
I've submitted an issue on the apparent loss of the unsigned cast in the test case you provided. I'll post here when I have more info.

Thanks for the test case!

Dale
0 Kudos
Dale_S_Intel
Employee
458 Views
This should be fixed in the next update. The issue number is CQ153444.

I'll try to post here again when the update is available.

Dale
0 Kudos
Dale_S_Intel
Employee
458 Views
It appears to be fixed in update6, you can download it at registrationcenter.intel.com.

Good Luck!

Dale
0 Kudos
Reply