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
------------------------------------------------------------------------------
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
