Re: h8300: less optimal (buggy?) compiler output with last build

[Kai Ruottu <kai.ruottu@luukku.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]

Ralf Gütlein wrote:
> 
> ----- Original Message -----
> From: Kazu Hirata <kazu@hxi.com>
> To: 'Ralf Gütlein' <ralf.guetlein@biotest-mt.de>; gcc <gcc@gcc.gnu.org>;
> 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