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

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

[Kazu Hirata]

Hi Ralf,

> extern unsigned char volatile TCW;
> 
> inline Watchdog()
> {
>   TCW = 0;
> }
> 
> void testcase_1(void)
> {
>   TCW = 0;
> }
> 
> void testcase_2(void)
> {
>   Watchdog();
> }
> 
> The h8 assembler source (compiled with -Os -fomit-frame-pointer):
> 
> 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.  Does your version actually output TCW, not @_TCW?
Have you applied any patches that are not in the cvs?

Kazu Hirata

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

[Ralf Gütlein]

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

----- 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.  Does your version actually output TCW, not @_TCW?
> Have you applied any patches that are not in the cvs?
>
> Kazu Hirata
>

Sorry but I made a typo. Of course, what the compiler emits reads:

testcase_2: sub   r2l, r2l
            mov.b r2l, @TCW
            mov.b @TCW, r2l  ; <-- ????
            rts

Still, this is a serious issue, which appears to be present on other
targets also. I can prove it at least for i586:

_testcase_1__Fv:
    movb    $0, _TCW
    ret
(...)
_testcase_2__Fv:
    movb    $0, _TCW
    movb    _TCW, %al   ; <-- ????
    ret

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.


Regards,
Ralf


           .....
           ô ô )
-----oOOo--(_)---oOOo------

Ralf Guetlein
Biotest Medizintechnik GmbH
Industriestrasse 19
D-63755 Alzenau
Germany
---------------------------
Tel. +49 6023 9487-42
Fax. +49 6023 9487-33
ralf.guetlein@biotest-mt.de
---------------------------

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

[Alan Lehotsky]

what happens if you change your inline to be...

	inline void Watchdog()
	{
	TCW = 0;
	}

so the front-end doesn't think it needs to return a value
of the last expression executed ? [Which I thought it
should be warning about 

	1/ function without a return type (implicit int)
	2/ value-returning function not returning a value

IIRC, these are BOTH C++ errors and -WALL warnings for C.

-- Al Lehotsky

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

[Kai Ruottu]

[-- 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

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

[Jeffrey A Law]

  In message < 399D30DE.E0DAAF45@luukku.com >you write:
  >  Ok, I then tested some simpler float-programs and none of them worked. Whe
  > n
  > looking one under GDB, I found it being in eternal loop in 'floatsisf()' in
  > '_floatdisf.o'/'libgcc.a'...
This is because one of Jakub's changes has badly broken our 16bit targets.

jeff

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

[Ralf Gütlein]

----- Original Message -----
From: Bill Knight <BillK@rosw.com>
To: gcc <gcc@gcc.gnu.org>; gnuh8 <gnuh8@pcserv.demon.co.uk>
Sent: Wednesday, August 16, 2000 6:01 PM
Subject: Re: h8300: less optimal (buggy?) compiler output with last build


> The compiler may be trying to "help" because of the implied
> int declaration of Watchdog().  You might try the following
> declaration for Watchdog() and recheck the results:
>
> inline void Watchdog(void)
> {
>   TCW = 0;
> }
>

One more typo in the rendering. My sources were correct, though...

To sum it up:
The compiler generates an unneccessary (and thus erroneous, even dangerous)
read acccess to a previously written location, if all of the following
conditions are true:

1) the object is volatile
2) the object is written to by an inline function
3) this inline function is called

example source (hopefully without typos ;-)

///////////////////////////////////////
extern volatile unsigned char TCW;

extern inline void WD(void)
{
  TCW = 0;
}

void test(void)
{
  WD();
}
///////////////////////////////////////

> >
> >Is this issue present in other ports?

This question has been answered already: yes!

> >Will this be investigated by somebody?
> >Or, could anybody give hints where to look for this issue in the sources?

These questions are still to be answered :-(

Regards,
Ralf

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

[Ralf Gütlein]

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

After some new discoveries in this case, I submitted a bug report to
gcc-bugs this morning.

See   http://gcc.gnu.org/ml/gcc-bugs/2000-08/msg00409.html

Regards,
Ralf


> To sum it up:
> The compiler generates an unneccessary (and thus erroneous, even
dangerous)
> read acccess to a previously written location, if all of the following
> conditions are true:
>
> 1) the object is volatile
> 2) the object is written to by an inline function
> 3) this inline function is called

           .....
           ô ô )
-----oOOo--(_)---oOOo------

Ralf Guetlein
Biotest Medizintechnik GmbH
Industriestrasse 19
D-63755 Alzenau
Germany
---------------------------
Tel. +49 6023 9487-42
Fax. +49 6023 9487-33
ralf.guetlein@biotest-mt.de
---------------------------

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

[Ralf Gütlein]

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

After installing the latest build of the h8 toolchain,
I realized that the compiler output (assembler source)
is worse than before (I used to use a snapshot from
December 99). One concrete example (cc the use of inline
functions):

extern unsigned char volatile TCW;

inline Watchdog()
{
  TCW = 0;
}

void testcase_1(void)
{
  TCW = 0;
}

void testcase_2(void)
{
  Watchdog();
}

The h8 assembler source (compiled with -Os -fomit-frame-pointer):

testcase_1: sub   r2l, r2l
            mov.b r2l, TCW
            rts

testcase_2: sub   r2l, r2l
            mov.b r2l, TCW
            mov.b TCW, r2l  ; <-- ????
            rts

As you can see, in the "inline" test case there is an erroneous read
of the previously written address.
This could be fatal (in case of an embedded system), when the
hardware doesn't "like" read access to a write-only position. So there
is good reason to treat this as a BUG.

As I mentioned before, this problem didn't occure in earlier versions
(e.g. Dec-99).

Is this issue present in other ports?
Will this be investigated by somebody?
Or, could anybody give hints where to look for this issue in the sources?

Regards,
Ralf

           .....
           ô ô )
-----oOOo--(_)---oOOo------

Ralf Guetlein
Biotest Medizintechnik GmbH
Industriestrasse 19
D-63755 Alzenau
Germany
---------------------------
Tel. +49 6023 9487-42
Fax. +49 6023 9487-33
ralf.guetlein@biotest-mt.de
---------------------------