This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/52394] SH Target: SH2A defunct bitops
- From: "olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 20 Sep 2015 03:36:42 +0000
- Subject: [Bug target/52394] SH Target: SH2A defunct bitops
- Auto-submitted: auto-generated
- References: <bug-52394-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52394
--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> ---
The SH2A bitops seem to produce some of the insns, but it seems the generated
code is either really bad (defeating the original purpose) or broken.
For example:
volatile struct
{
union
{
unsigned char BYTE;
struct
{
unsigned char BIT7:1;
unsigned char BIT6:1;
unsigned char BIT5:1;
unsigned char BIT4:1;
unsigned char BIT3:1;
unsigned char BIT2:1;
unsigned char BIT1:1;
unsigned char BIT0:1;
}
BIT;
}
ICR0;
}
USRSTR;
int
main (unsigned char a, unsigned char b, unsigned char c)
{
USRSTR.ICR0.BIT.BIT5 |= b & 1;
return 0;
}
compiled with -m2a -mb -mbitops -O2:
mov.l .L2,r2 // addr of USRSTR
mov #1,r1
and r1,r5 // b & 1
mov #0,r0
bor.b #5,@(0,r2) // T |= (bit in mem)
movt r7 // r7 = T
mov.b @r2,r3 // load byte
cmp/pl r7 // T = r7
mov #5,r7
movt r1 // r1 = T
bclr #5,r3 // clear bit 5 of loaded byte
shld r7,r1 // T << 5
or r3,r1 // OR bit
mov.b r1,@r2 // write back
rts/n
It seems that this will produce funny results at the first bor.b insn because
at function entry the T bit is undefined.
The code should actually be something like this:
mov.l .L2,r2
bld #0,r5
mov #0,r0
bor.b #5,@(0,r2)
bst.b #5,@(0,r2)