User account creation filtered due to spam.
In an inlined method, we cast a double argument into an INT64& : with gcc4.2.1 (not with other versions or compilers), this gives a completely false result that leads to a crash. To avoid this, we had to create an INT64 on the stach and to memcpy the double into it, which is much less optimized... Of course, we compile with full (O3) optimization. With O0, this works.
You are violating C aliasing rules. Use memcpy (as you did) or a union to guard
the type punning.
*** This bug has been marked as a duplicate of 21920 ***
(In reply to comment #1)
> You are violating C aliasing rules. Use memcpy (as you did) or a union to
> the type punning.
> *** This bug has been marked as a duplicate of 21920 ***
Are-you sure? Were is the rule that forbids to do this?
And even if this is the case, this is for us a crucial matter of optimization: other compilers allow that, and optimize this cast. If gcc cannot do that (which also means that you (double*)(void*)(&d) should not work too), it should at least provide a way to do such an operation more efficiently that doing a memcpy!
An how do-you explain that without optimization it works, then?
For us, it is a big problem, and this means that we cannot really rely on gcc!
The recommended (and optimized) way to do this is:
x.d = arg;
you can also make your way work optimized by specifying -fno-strict-aliasing.
That it works without optimization is because with that or with -O1
-fno-strict-aliasing is default.
Try compiling with -fno-strict-aliasing. This is only automatically enabled at -O2 or higher. See the fine manual.
I'm not sure what you mean with "more efficient than memcpy". If you mean more efficient as in producing better code: Have you actually checked what comes out of the compiler if you do this? If you mean more elegant from a coding style point of view: The language provides the means, it is called "union".