http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #8 from Tomohiro Kashiwada <kikairoya at gmail dot com> 2011-10-28
03:58:45 UTC ---
(In reply to comment #7)
> Right. r171347 seem to be about fetches from bitfields while this change is
> about stores?
>
> An interesting test would be
>
> bitfield.bits.a = bitfield.bits.c
>
> which should load the int to a register, load the int again to another
> register, copy c to a between them and store the result. I guess the double
> load may be optimized away as it's an sideeffect of the aassignment.
Both r171346 and r171347 (target=rx-elf, byte and bit little-endian) generates:
mov.L #_bitfield, r14
mov.L [r14], r4
shlr #24, r4
mov.L r4, [r14]
r171347 with my patch generates:
mov.L #_bitfield, r14
mov.L [r14], r3
shlr #24, r3
mov.L [r14], r4
and #0xffffffffffffff00, r4
or r3, r4
mov.L r4, [r14]
in this code, loads twice. I don't know the Standard C or C++ requires double
load or not.
When -fno-strict-volatile-bitfields, generates
mov.L #_bitfield, r14
mov.B 3[r14], r4
mov.B r4, [r14]
this code is seems ok but GCC ignores alignment (configuration of rx-elf has
STRICT_ALIGNMENT).
Another test,
bitfield.bits.a = bitfield.bits.a;
r171346 and r171347 generates:
mov.L #_bitfield, r14
mov.L [r14], r4
movu.B r4, r4
mov.L r4, [r14]
r171347 with my patch:
mov.L #_bitfield, r14
mov.L [r14], r3
movu.B r3, r3
mov.L [r14], r4
and #0xffffffffffffff00, r4
or r3, r4
mov.L r4, [r14]
