On 09/05/10 18:32, Denys Vlasenko wrote:
On Sun, Sep 5, 2010 at 4:59 PM, Cristian Ionescu-Idbohrn
<[email protected]> wrote:
On Sun, 5 Sep 2010, Denys Vlasenko wrote:
What do you propose to do?
Up to the maintainer ;) But this is the advise:
This can be temporarily worked around by using
-fno-strict-aliasing
Performance hit.
But IMO the only sane short-term solution.
The other option would be not to use -O2 (or higher), and that would
be the bigger performance hit.
Or risk that the optimizer generates wrong code and spend weeks and
month hunting such bugs.
To fix, access the structure from pointers
of an equivalent type, use a union, use memcpy,
This will be ugly.
IMHO using undefined behaviour is uglier.
Or using __may_alias__.
But ugliness is a matter of taste.
or (if using C++)
use placement new. See the section titled "Casting does not work
as expected when optimization is turned on" on bug reporting
documentation page for more information.
and points to another page:
http://gcc.gnu.org/bugs/
and an article:
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
I would vote for fixing the code generating 183+ warnings, but I realize
that takes some effort.
That's the only clean long-term solution.
BTW, the example given at <http://gcc.gnu.org/gcc-4.4/porting_to.html>
is misleading:
char buf[sizeof(struct A)];
((struct A*)buf)->i = 4;
This might be more an alignment problem than a aliasing problem, as
ISO C explicitely allows aliasing of character type lvalues, which buf
clearly is.
And GCC correctly doesn't warn about the usual idiomatic use:
char *buf = malloc(sizeof(struct A));
((struct A*)buf)->i = 4;
Detlef
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
