Fw: gnuH8: BUG still there in egcs-1.1.2

["Gütlein" <ralf dot guetlein at rhein-main dot netsurf dot de>]

I forward a bug report to you which I sent also to the gnuH8 mailing list.

This bug appeared in the egcs cross compiler binaries configured as:

--host=i586-pc-cygwin32 --target=h8300-hms

Regards,
R. Guetlein

----------
> Von: Gütlein <ralf.guetlein@rodgau.netsurf.de>
> An: gnuh8 <gnuh8@pcserv.demon.co.uk>
> Betreff: gnuH8: BUG still there in egcs-1.1.2
> Datum: Montag, 31. Mai 1999 15:44
> 
> Bug still there in GNU compiler version egcs-1-1-2
> ====================================
> 
> 
> I recently downloaded cross compiler binaries for win32 host from
somewhere
> (can't remember the URL; had sth. to do with "LegOS").
> 
> I realized that this version has no major changes in compiler output
> compared
> to 97r2 - even the bug I mentioned a few months ago is still "working"
> (joke ;-)
> 
> 
> The following source (useless and dangerous because the addresses 
> stored in static pointers are becoming invalid after return from bug() )
> 
> 
> typedef unsigned char byte;
> 
> byte *d, *e, *f;
> 
> void bug (byte a, byte b, byte c)
> {
>    d = &a;
>    e = &b;
>    f = &c;
> }
> 
> compiled with
> 
> cc1 bug.c -O1
> 
> results in the following assembler output:
> 
> _bug:
> 	push	r6
> 	mov.w	r7,r6
> 	subs	#2,sp
> 	subs	#2,sp
> 	mov.w	r0,@(-2,r6)      //<-- the error is here!!!
> 	mov.b	r2l,@(-3,r6)
> 	mov.w	r6,r2
> 	subs #1,r2
> 	mov.w	r2,@_d
> 	mov.w	r6,r2
> 	subs #2,r2
> 	mov.w	r2,@_e
> 	mov.w	r6,r2
> 	subs #2,r2
> 	subs #1,r2
> 	mov.w	r2,@_f
> 	adds	#2,sp
> 	adds	#2,sp
> 	pop	r6
> 	rts
> 
>
----------------------------------------------------------------------------

> --------------------------------------------
> 
> Details
> =====
> The first three char or int parameters of any function are passed through
> registers r0, r1, r2 (int) and r0l, r1l, r2l (char), respectively.
> If the compiler needs additional registers for local variables or
> expression
> evaluation, or if a parameter is referenced by address (see example
above),
> the relevant parameter(s) is/are stored in the local stack frame. In some
> cases this is done incorrectly.
> 
> The compiler generates 
> 	mov.w r0,@(-2,r6)  //error
> instead of
> 	mov.b r0l,@(-1,r6) //correct sequence
> 	mov.b r1l,@(-2,r6)
> or instead of
> 	mov.b r1l,r0h        //also correct
> 	mov.w r0,@(-2,r6)
> 
> causing that parameter "b" is discarded, and an undefined value (the
> unknown
> value of r0h) is used instead.
> 
> The compiler seems to assume (in this one case) that byte parameters are
> passed in packed form (r0l, r0h, r1l and so on). The IAR compiler, for
> example
> uses this method to save registers (BTW a good suggestion for
improvement!)
> 
>
----------------------------------------------------------------------------

> --------------------------------------------
> 
> Workarounds
> ==========
> To avoid unpredictable effects caused by this bug, several workarounds
may
> be
> applied:
> 1) Use only parameters longer than char (that is int, longint)
> 	Disadvantage: not very effective on a byte machine
> 2) Use char parameters only if it is save to do so.
> 	Don't ask me when it is save! You have to proof assembler output to be
> 	sure. In my experience it is save in small functions that don't call
>             other functions. As long as the compiler is able to keep
those
>             parameters in registers, it will not produce erroneous code
(At
> least not
> 	regarding *this* bug :-)
> 3) Switch off optimisation (-O0).
> 	The worst alternative in my opinion.
> 
>
----------------------------------------------------------------------------

> --------------------------------------------
> 
> Request for Bugfix
> =============
> 
> Is there anybody with enough knowledge and practice to suggest (or
> implement)
> a bugfix? I would be glad to play a "beta tester" for him.
> 
> 
> Regards,
>  Ralf
> 
> 
>