Hi Doug,
> Here's a better example, while pretty contrived, that shows how the
> compiler can optimize away things due to aliasing rules.
>
> What do you expect the output of the printf to be? In the -O2 and
> better case, I can tell you that gcc 4.4 differs from gcc 4.5, and is
> probably not what you expect.
>
> #include <stdio.h>
>
> int main()
> {
> unsigned int itmp; unsigned short stmp;
> unsigned int i = 0x12345678;
> double f = 3.14159265358979323846;
>
> unsigned short* sarr = (unsigned short*)&i;
> unsigned int* iarr = (unsigned int*)&f;
>
> itmp = *iarr; *iarr = *(iarr+1); *(iarr+1) = itmp;
> stmp = *sarr; *sarr = *(sarr+1); *(sarr+1) = stmp;
> printf("swapped float = %0.25g, swapped int = 0x%X\n", f, i);
> return 0;
> }
Wow. That's very strange. Thanks for sharing.
In fact, the float isn't needed even. Having the integer alone and
swapping its bytes is enough to demonstrate the discrepancy. And if
one uses -fno-strict-aliasing, the code compiles "as expected"
regardless of optimization level.
> On that note, what you ran across is a difference in how glibc is
> behaving with respect to malloc versus how gcc expects malloc to
> behave. We suffered the same issue recently with the math functions
> that were potentially writing to a global unexpectedly....basically
> our declarations "lied" to gcc about the behavior of the functions
> :)...
Yes, indeed.
Paarvai
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
