Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
15 Views

malcompilure?

/*
* 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
Highlighted
Black Belt
15 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
Highlighted
Beginner
15 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
Highlighted
Black Belt
15 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
Highlighted
Beginner
15 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
Highlighted
Black Belt
15 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
Highlighted
Employee
15 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
Highlighted
Employee
15 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
Highlighted
Employee
15 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
Highlighted
Employee
15 Views

It appears to be fixed in update6, you can download it at registrationcenter.intel.com.

Good Luck!

Dale
0 Kudos