Under unclear circumstances, some functions cause code to copy function parameters to local area of stack frame. Parameters are copied at declared size (unsigned short gets 2 bytes). If parameters are modified in function body, emitted code may use a long (4 byte) mode directly to the copied parameter in the local stack frame. I have an example from a fragment of the lwIP TCP/IP source that causes the problem. An unsigned short parameter was copied to -2(% a6) and then later in the function an add.l %d1,-2(%a6) was emitted to perform a ++ operation on the parameter. This blows %a6 when the function returns and crashes the code. This particular instance only occurs when -O2 is used and only on Coldfire targets. On other m68k family processors, an add.w %d1,-2(%a6) is generated instead which works OK. With lower optimization levels, the code loads the value into a register, modifies it, and stores it with a move.w %d1,-2 (%a6). It is possible that this bug relates to bug #8309. I have a file tcpout2.ii (which I can provide) that demonstrates the problem. My host and build system is Cygwin under Win 2000. My command line is: m68k-elf-gcc -m5200 - O2 -S tcpout2.ii
Created attachment 5283 [details] A C++ preprocessed source file to demonstrate the bug
Bernardo, you frequently build for this target. Would you mind commenting on this report? Thanks.
I've tried to reproduce this problem with: - GCC 3.4 (20040114) + Andreas cc0 patch - GCC 3.3.3 (20031222) + my ColdFire/uClinux patch set In both cases, the generated code seems to be correct, assuming I'm looking at the same variable: GCC 3.4: move.w %d0,-2(%a6) [...] clr.l %d0 move.w -2(%a6),%d0 add.l %d0,88(%a5) move.w 94(%a5),%d0 GCC 3.3.3: move.w %d0,-6(%a6) [...] clr.l %d0 move.w -6(%a6),%d0 add.l %d0,88(%a4) move.w 94(%a4),%d0 Please test with the latest 3_3-branch snapshot. If you still see the problem, try applying all these patches in the given order: http://www.develer.com/uclinux/uclinux-tools-20031230/gcc-3.3.2-coldfire-targets.patch http://www.develer.com/uclinux/uclinux-tools-20031230/gcc-3.3.2-coldfire-frame.patch http://www.develer.com/uclinux/uclinux-tools-20031230/gcc-3.3.2-uclinux-idshlib.patch http://www.develer.com/uclinux/uclinux-tools-20031230/gcc-3.3.2-uclinux-thunk.patch http://www.develer.com/uclinux/uclinux-tools-20031230/gcc-3.3.2-uclinux-specs.patch http://www.develer.com/uclinux/uclinux-tools-20031230/gcc-3.3.2-coldfire-omitfrmptr.patch The uClinux patches are not relevant to you, but you need them in order to apply dependent ColdFire patches. If any of these patches fixes the problem for you, I'll prepare a standalone version that applies to 3_3-branch and submit it for this PR.
Stepehen, would it be possible for you to check 3.3 branch with the patches Bernie mentioned to see if this is still present? Thanks.
gcc-3.3-20040119 both with and without Bernardo's patches produces the bug. I shall try gcc-3.4-20040121.
I built gcc-3.4-20040121. It took a little doing because newlib-1.11.0 (the revision I've been using) had a bunch of fatal compile errors that I had to fixup (apperently the 3.4 compile is pickier about certain things). The same problem persists.
Subject: Re: [m68k] C++ produces stack frame damaging code for Coldfire Steve at Zook dot com wrote: > ------- Additional Comments From Steve at Zook dot com 2004-01-25 05:01 ------- > I built gcc-3.4-20040121. It took a little doing because newlib-1.11.0 (the > revision I've been using) had a bunch of fatal compile errors that I had to > fixup (apperently the 3.4 compile is pickier about certain things). The same > problem persists. Please submit patches to the newlib guys.
Okay confirmed then. Hopefully somebody'll look at this though...
I'll hopefully have some time to analyze this regression along with a few other m68k target bugs after the next week. Of course, I wouldn't mind if sombody else can fix it before I do :-)
Sorry, I promised I'd have a look at it but a lot of time has passed. Could you please submit -S output of GCC 3.4.0 along with the exact command line you used to produce it? Please mark the point in the code where the erratic instruction is being generated.
Created attachment 6491 [details] Bug generated with gcc-3.4.0 On line 365 of tcpout2.s the compiler has generated add.l %d7,-2(%a6) which will be fatal. I also see on line 181 a sub.l -2(%a6),%d0 which will work but may indicate other problems. The file tcpout2.s (attached in tcpout2.tar.bz2 along with tcpout2.ii from which it was compiled) was generated using gcc-3.4.0 and command line m68k-elf-gcc -m5200 -O2 -S tcpout2.ii.
This patch does indeed fix the bug: http://gcc.gnu.org/ml/gcc/2004-05/msg01357.html 2004-05-27 Peter Jakubek <peter@laseranimation.com> * reload.c (find_reloads): force reload for pseudo registers on big endian machines. The generated code to increment the word at -2(a6) with the patch applied looks like this: move.w -2(%a6),%d7 moveq #1,%d4 add.l %d4,%d7 move.w %d7,-2(%a6) jbra .L122 *** This bug has been marked as a duplicate of 8309 ***