Alex Gonzalez writes: > Hi, trying to come up with a testcase we figured out what the problem could > be. > > When the optimizer is on and memcpy sees that it is copying a > struct with double words in it, it will assume that the struct > starts on an 8 byte boundary and use double word loads and > stores. This is a safe assumption, as gcc will always ensure that > structs containing doubles start on an 8 byte boundary when the > memory is mallocced. > > However we managed to trick gcc by mallocing a large chunk of > memory and then assigning a pointer to a user data (unsigned int > user[0]) without first ensuring that the user data was 8 byte > aligned. Since the structure does contain a double, this resulted > in a crash in memcopy. > > The fix for this was to inform the compiler that this "void" > pointer should be 8 byte aligned by changing the "unsigned int > user[0]" to a "unsigned long long user[0]". This will cause gcc to > pad this entry out to ensure that it starts on an 8 byte boundary. > > Does this make sense?
Yes. In general, if you lie to the compiler you lose. :-) It's a very good idea to read what the language standards actually say about this. In particular, casting pointers between types doesn't work except in some well-defined cases. You should read the standard to find out what works and what doesn't. Andrew.