From: Paarvai N. <ope...@gm...> - 2010-06-30 23:05:29
|
Hi Doug, > Have you filed a bugzilla report for gcc against this bug? If it is > an optimization wrong code bug, then it probably exists for other > targets besides mingw32. Yes, it's a problem across targets. I first caught it when compiling for an x86_64-linux target. > For example, a > common occurrence in migrating to compiling with gcc 4.5+ is better > optimizations of pointer aliasing handling such as the following: > > #include <stdio.h> > > double s = 123; > int main() > { > unsigned int* pc = (unsigned int*)&s; > *pc = 43; > printf("%f", s); > return 0; > } > > Optimization is free to print 123.00000 (seemingly unexpectedly) in > these cases. While this may seem like a bug in gcc, it's actually a > bug in the user's code, exposed by the optimizer. I'm very confused by this example, and not sure what you are trying to get at. In fact, I feel as though the behavior you are talking about is fully expected and doesn't seem to have anything to do with optimization. 1) A double is 8 bytes long. 2) The assignment using the int pointer only alters 4 bytes of that. 3) The 4 bytes that are altered are the 4 least-significant bytes (on x86 or other Little Endian machines, at least) 4) As such the alteration is beyond the default precision of your %f format string. This modified example might make things more clear: --- #include <stdio.h> #include <stdint.h> double s = 123; int main() { unsigned int* pc = (unsigned int*)&s; uint64_t *val = (uint64_t *)&s; printf("s before alteration = %f\n", s); printf("raw repr of s before alteration = 0x%16lx\n", *val); *pc = 0x43; printf("s after alteration = %f\n", s); printf("raw repr of s after alteration = 0x%16lx\n", *val); return 0; } --- Please do let me know if I'm missing something here. Yes, I am planning on posting my find on the GCC Bugzilla. I'm pretty sure it's a case of over-optimization (and a critical one at that), but I freely admit that I'm not an expert on the internals of GCC. :) > I personally wouldn't do a mulitlib compiler with 4.4 series, but just > have two compilers, one that targets i686-w64-mingw32 and one that > targets x86_64-w64-mingw32. Yes, I considered that, but I'd highly prefer that my toolchain (which includes a multilib Linux GCC and multilib Darwin GCC as well) be consistent if possible. > In fact, even with the 4.5 and 4.6 series, multilib requires a bit of > work to ensure that the installed DLLs are correctly placed on the > build system. This doesn't even take into consideration placement of > the runtime libraries on the end user's system. Yes, thanks. I had noticed that before too with 4.5, and moved some binary DLLs around appropriately in the bin directory (bin/32 and bin/64). Cheers, Paarvai |