Ralf Gütlein wrote: > > ----- Original Message ----- > From: Kazu Hirata > To: 'Ralf Gütlein' ; gcc ; > gnuh8 > > > testcase_1: sub r2l, r2l > > > mov.b r2l, TCW > > > rts > > > > > > testcase_2: sub r2l, r2l > > > mov.b r2l, TCW > > > mov.b TCW, r2l ; <-- ???? > > > rts > > > > This sounds serious. I am using the latest gcc from the cvs, but this > > problem did not happen. > > This is happening only with the c++-compiler, the c-compiler issues the > expected code. IMO this means that the error must be somewhere within > the target-independend part of the sources. > > This applies to last weeks snapshot. I don't know how long this has been > an issue, because I haven't been involved in GCC for a while. I built the egcs-20000814 for H8/300 (only Linux still), and checked this with the 'h8300-hms-g++'... Adding the missing return type and argument types didn't remove the bug... Sounds quite related to the 'volatile' (where else we have seen this 'feature'?), but didn't check what removing it would cause... More serious bug now seems to be the slowness and the big size of the compilers -- the 'cc1plus' is now about 3 Mbytes under Linux/x86, Win32 and DOS/DJGPP... When I tried the 'arm-epoc-pe' target (all headers and libs are pure C++...), I found the compiler being very slow under Linux and Win32 (Mingw) hosts, and unusable under DOS/DJGPP, the simple 'hellotext.cpp' example from the Wrox Press EPOC-book took several minutes to compile under DOS/Win3.11/DJGPP- host with the 'gcc-2.96-arm-epoc' compiler. Can be a DJGPP2.03-problem... I didn't rebuild my H8/300 C-libraries (newlib-1.8.2, built with gcc-2.95.2 earlier) with the snapshot, but tried to use the old libs. When being curious if the new 'libgcc.a' would have any speed-up in the FP-routines (fp-bit.c), I compiled the IAR-testprogram for floats and linked with the old 'libc.a / libm.a'. And waited the run to stop and give results under the standalone run-simulator with GDB... Waited and waited... After 2 minutes I then hit Ctrl-C... Ok, I then tested some simpler float-programs and none of them worked. When looking one under GDB, I found it being in eternal loop in 'floatsisf()' in '_floatdisf.o'/'libgcc.a'... Then I tried 'mcore-elf', it behaved just the same way, and then I remembered some of the earlier snapshots being broken with floats in 'arm-elf' too. In the beginning of May the snapshots were totally broken for everything and even now they haven't stabilized so that they be used for anything serious. I was happy when seeing the 'arm-epoc' to compile and link ok, but not being capable to test the executables, this doesn't prove anything... I have raised my hands up... I would like to have a bug-fix-release instead (gcc-2.95.3...), perhaps the gcc-2.9-edk-000221 could serve as the 'current stable release'... Cheers, Kai