This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mips gcc -O1: Address exception error on store doubleword


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]