RE: Still fails with strict-volatile-bitfields

[Bernd Edlinger <bernd dot edlinger at hotmail dot de>]

Hi,

On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
>
> Sandra, Bernd,
>
> Can you take a look at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
>
> It seems a siimple case still doesn't work as expected. Did I miss anything?
>
> Thanks,
> Joey

Yes,

this is a major case where the C++ memory model is
in conflict with AAPCS.

You can get the expected code, by changing the struct
like this:

struct str {
  volatile unsigned f1: 8;
  unsigned dummy:24;
};

If it is written this way the C++ memory model allows
QImode, HImode, SImode. And -fstrict-volatile-bitfields
demands SImode, so the conflict is resolved. This dummy
member makes only a difference on the C level, and is
completely invisible in the generated code.

If -fstrict-volatile-bitfields is now given, we use SImode,
if -fno-strict-volatile-bitfields is given, we give GCC the
freedom to choose the access mode, maybe QImode if that is
faster.

In the _very_ difficult process to find an solution
that seems to be acceptable to all maintainers, we came to
the solution, that we need to adhere to the C++ memory
model by default. And we may not change the default
setting of -fstruct-volatile-bitfields at the same time!

As a future extension we discussed the possibility
to add a new option -fstrict-volatile-bitfields=aapcs
that explicitly allows us to break the C++ memory model.

But I did not yet try to implement this, as I feel that
would certainly not be accepted as we are in Phase3 now.

As another future extension there was the discussion
about the -Wportable-volatility warning, which I see now
as a warning that analyzes the structure layout and
warns about any structures that are not "well-formed",
in the sense, that a bit-field fails to define all
bits of the container.

Those people that do use bit-fields to access device-registers
do always define all bits, and of course in the same mode.

It would be good to have a warning, when some bits are missing.
They currently have to use great care to check their structures
manually.

I had a proposal for that warning but that concentrated
only on the volatile attribute, but I will have to re-write
that completely so that it can be done in stor-layout.c:

It should warn independent of optimization levels or actual
bitfield member references, thus, be implemented entirely at
the time we lay out the structure. The well-formed-ness of
a bit-field makes that possible.

But that will come too late for Phase3 as well.


Regards
Bernd.