https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79209

            Bug ID: 79209
           Summary: AArch64: Inconsistent packed volatile bitfield
                    accesses
           Product: gcc
           Version: 7.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: p...@gcc-bugzilla.mail.kapsi.fi
  Target Milestone: ---

Created attachment 40571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40571&action=edit
Packed volatile bitfield testcase for both C and C++.

Hi.

It seems that volatile bitfield structures with the packed attribute set (that
are not accompanied with an aligned attribute) are accessed quite
inconsistently. The instruction used to access the volatile bitfield depends on
the optimization level, the bitfield width and the the value itself.

Moreover, -fstrict-volatile-bitfields seems to have no particular effect on
this matter (e.g. only a temporary register used to access field was changed).
Yes, noticed that there was a note regarding packed fields in the manual, but
perhaps I expected it to only cover some rare special cases.

Consider the following structure and function:

struct __attribute__((packed)) S0
{
        unsigned volatile int y : 1;
        unsigned volatile int x : 2;
        unsigned volatile int z : 29;
}

volatile struct S0 * fn();

When updating the structure GCC generally prefers ldr w/str w (word) pair,
which is to be expected. However, based on the value being written GCC may
access the structure using ldrb w/strb w (byte) pair; usually if structure
access is not inlined and and/orr instruction is chosen based on the value
being written. Of course, should the underlying hardware only support word
access byte access will of couse fail -- hence the volatile bitfield in the
first place.

With both packed and aligned attributes set everything works as expected. I
guess the packed bitfields have been somewhat difficult thing to define and
agreed on, so a warning message (and a documentation entry explaining it) would
be just fine. Certainly could be just that I'm wrong, but as this was a tad
difficult to spot I'd still prefer it any day of the week.

Tested using GCC 6.2, 6.3 and 7.0.1 (trunk) and they all produce pratically
identical results. Both C and C++ frontends share this same mishap or feature.

aarch64-none-elf-gcc -Wall -Wextra -mabi=lp64 -fstrict-volatile-bitfields
-fno-exceptions -xc++ {-O0,-Og,-O1,-O2,-O3} -S packed-volatile-bitfield.in -o -

Reply via email to