This is the mail archive of the
mailing list for the GCC project.
RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 2/2
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: DJ Delorie <dj at redhat dot com>, Sandra Loosemore <sandra at codesourcery dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Thu, 17 Oct 2013 15:04:03 +0200
- Subject: RE: [PATCH] reimplement -fstrict-volatile-bitfields v4, part 2/2
- Authentication-results: sourceware.org; auth=none
- References: <52463D60 dot 8040607 at codesourcery dot com>,<201309302018 dot r8UKIU9g004905 at greed dot delorie dot com> <DUB122-W29B621BE86DA0D30377F19E41D0 at phx dot gbl> <201310162346 dot r9GNk6Zb013168 at greed dot delorie dot com> <525F4881 dot 30900 at codesourcery dot com>,<201310170250 dot r9H2oKkv017657 at greed dot delorie dot com>
On Wed, 16 Oct 2013 22:50:20, DJ Delorie wrote:
> Not all of them can work, because they describe something that can't
> be done in hardware. For example, the first test has an incomplete
> bitfield - the fields do not completely describe an "int" so the
> structure is smaller (one byte, according to sizeof()) than the access
> type (2-8 bytes).
where in the C standard did you read the requirement that every bit
field must be complete? (This is a serious question).
volatile unsigned int b : 1;
on my compiler this structure occupies 4 bytes.
and it is aligned at 4 bytes.
That is OK for me and AAPCS.
But the access "bf3.b=1" is SI mode with Sandra's patch (part 1, which just
obeys the AAPCS and does nothing else)
and QI mode without this patch, which is just a BUG.
I am quite surprised how your target manages to avoid it?
It is as Sandra said, at least on ARM -fstrict-volatile-bitfields
does not function at all. And the C++11 memory model wins all the time.
> Looking through the tests, most of them combine "packed" with
> mismatched types. IMHO, those tests are invalid.
I dont think so. They are simply packed. And volatile just says that
the value may be changed by a different thread. It has a great
impact on loop optimizations.
>>> Either way, if -fstrict-volatile-bitfields does not do what it's
>>> supposed to do, the correct action is to fix it - not to disable it on
>>> targets that rely on it for correct operation.
Agreed. That is the number one priority here.
> I've not objected to fixing -fstrict-volatile-bitfields, or making the
> -fno-strict-volatile-bitfields case match the standard. I've only
> objected to breaking my targets by making that flag not the default.
Fine. Why cant we just get this fixed?