------- Comment #4 from j3p0uk at hotmail dot com 2005-11-09 17:25 ------- The test case was a simple test case where I tried to show the mathematical behaviour in as simple a way as possible.
The reason I thought that this may be a bug is because the behaviour on a 64-bit system is different as no sign extension would occur during the divide operation, hence the two values would be the same (0x2a36c000) - and I've run the test program on an ia64 to prove this. Given this fact the pointer arithmetic in this case is giving an answer that is wrong (0xea36c000), and the reason for this can clearly be shown to be sign-extension occurring when possibly it should not. 0xcceb0000 - 0x24100000 1010 1000 1101 1011 0000 0000 0000 0000 ^ Highest order bit set 0x2a36c000 0010 1010 0011 0110 1100 0000 0000 0000 ^^ 0xea36c000 1110 1010 0011 0110 1100 0000 0000 0000 ^^ I admit that I hadn't thought about the case of a larger - smaller pointer, so would agree that the fix isn't as simple as I thought, but that doesn't change the fact that the current answer given is incorrect for the test program I was using. If you think the test program should be altered in any way to more correctly determine the behaviour but need a large memory system to run it on then I'll be more than happy to run it for you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24756
