This is the mail archive of the
mailing list for the GCC project.
[ping**3] Re: [patch 0/4] reimplement -fstrict-volatile-bitfields, v3
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Eric Botcazou <ebotcazou at adacore dot com>, <bernd dot edlinger at hotmail dot de>
- Date: Mon, 29 Jul 2013 00:33:23 -0600
- Subject: [ping**3] Re: [patch 0/4] reimplement -fstrict-volatile-bitfields, v3
- References: <51D0F66B dot 6010507 at codesourcery dot com> <51DC390E dot 9070904 at codesourcery dot com> <51EAE108 dot 5030601 at codesourcery dot com>
On 07/20/2013 01:12 PM, Sandra Loosemore wrote:
On 07/09/2013 10:23 AM, Sandra Loosemore wrote:
On 06/30/2013 09:24 PM, Sandra Loosemore wrote:
Here is my third attempt at cleaning up -fstrict-volatile-bitfields.
...and ping again.
...and again. Hmmm.
volatile int approved:1;
volatile int rejected:1;
volatile int needs_changes:1;
extern struct patch_status s;
while (!s.approved && !s.rejected && !s.needs_changes)
sleep (a_week_or_two ());
Part 1 removes the warnings and packedp flag. It is the same as in the
last version, and has already been approved. I'll skip reposting it
since the patch is here already:
Part 2 replaces parts 2, 3, and 4 in the last version. I've re-worked
this code significantly to try to address Bernd Edlinger's comments on
the last version in PR56997.
Part 2: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00001.html
Part 3 is the test cases, which are the same as in the last version.
Nobody has reviewed these but I assume they are OK if Part 2 is
Part 4 is new; it makes -fstrict-volatile-bitfields not be the default
for any target any more. It is independent of the other changes.
Part 4: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00002.html
It seems that the change to the defaults in part 4 is still
controversial but my understanding based on discussion of the previous
version of the patches is that the maintainers were going to insist on
that as a condition of getting the other bug fixes in. From my
perspective, I'd be happy just to wrap up this patch series somehow or
another, so please let me know if there are additional changes I need to
make before this is suitable to check in.
Please note that I'm pinging my own 4-part patch series, not the Bernd's
followup patch confusingly posted in the same thread.