This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bitfield handling on m68k broken
- From: Andreas Schwab <schwab at suse dot de>
- To: Roman Zippel <zippel at linux-m68k dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 24 Apr 2007 16:22:14 +0200
- Subject: Re: bitfield handling on m68k broken
- References: <Pine.LNX.4.64.0704241530460.2958@scrub.home>
Roman Zippel <zippel@linux-m68k.org> writes:
> This is taken from execute/20040709-1.c:
>
> struct K { unsigned int k : 6, l : 1, j : 10, i : 15; };
> struct K retmeK (struct K x)
> {
> return x;
> }
>
> This produces the following code:
>
> retmeK:
> link.w %fp,#0
> move.l %d3,-(%sp)
> move.l %d2,-(%sp)
> clr.l %d0
> move.l 8(%fp),%d1
> bfextu %d1{#7:#10},%d3
> bfextu %d1{#17:#15},%d2
> bfins %d2,%d0{#17:#15}
> bfins %d3,%d0{#7:#10}
> -> moveq #26,%d2
> lsr.l %d2,%d1
> bfins %d1,%d0{#0:#7}
> move.l (%sp)+,%d2
> move.l (%sp)+,%d3
> unlk %fp
> rts
The code generated by 4.3.0 20070122 still looks correct.
> Even without this bug gcc usage of bitfield instruction has become a
> little insane lately, e.g. 2.95/3.4 produce this code:
>
> retmeK:
> link.w %a6,#0
> move.l 8(%a6),%d0
> unlk %a6
> rts
FWIW, I get this very code with 4.3.0 20070122 when compiling without
optimisation.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."