------- Comment #11 from shcherbakov at daad-alumni dot de 2010-02-10 12:44
-------
Ok, m32c uses "memcpy" for all block moves (4 ints is a DImode, not BLKmode).
Additionally, it supports pre-decrement addressing mode, that enables a
mutually exclusive case to the one showing the bug.
To reproduce the bug on m32c, change the following:
1. in m32c.h replace "#define HAVE_PRE_DECREMENT 1" with 0
2. Comment out "(define_expand "movmemhi"" in blkmov.md
Then, compiling the example with structure containing 5 integers produces this:
.file "0.c"
.text
.global _func1
.type _func1, @function
_func1:
enter #0
push.w 7[fb]
push.w 5[fb]
mova 9[fb],a0
push.w 2[a0]
push.w [a0]
push.w 4[a0]
jsr.a _func2
add.w #10,sp
exitd
.size _func1, .-_func1
.ident "GCC: (GNU) 4.4.3"
Obviously, the push order (fp+7,fp+5,fp+11,fp+9,...) is incorrect.
Note that removing hardcoded "memcpy" call and commenting out pre-increment
support was needed ONLY to reproduce the bug normally happening on MSP430 using
a supported M32C platform.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722
