This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Fw: gnuH8: BUG still there in egcs-1.1.2
- To: <egcs-bugs at egcs dot cygnus dot com>
- Subject: Fw: gnuH8: BUG still there in egcs-1.1.2
- From: "Gütlein" <ralf dot guetlein at rhein-main dot netsurf dot de>
- Date: Mon, 31 May 1999 15:58:37 +0200
- Cc: <law at cygnus dot com>
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
>
>
>