public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <rdsandiford@googlemail.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [6/8] Add strict volatile handling to bit_field_mode_iterator
Date: Thu, 15 Nov 2012 12:25:00 -0000	[thread overview]
Message-ID: <87fw4bvyrv.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> (raw)
In-Reply-To: <1775073.QASfiHdzOH@polaris> (Eric Botcazou's message of "Tue, 13	Nov 2012 14:56:05 +0100")

Thanks for the reviews.

Eric Botcazou <ebotcazou@adacore.com> writes:
>> This patch makes bit_field_mode_iterator take -fstrict-volatile-bitfields
>> into account, in cases where the size of the underlying object is known.
>> This is used in the next patch.
>
> Do we really need to add that to the iterator?  The -fstrict-volatile-
> bitfields implementation is still controversial so I'm not sure that we want
> let it spread.  Can't the client code just skip the problematic modes?

The idea was to centralise the knowledge about what modes are valid
rather than requiring every client to know the rules.  From that point
of view it seems inconsistent for the new interface to handle the
bitregion_{start,end} restrictions (a correctness issue) but not the
volatility restrictions (also a correctness issue).  Especially when the
interface already knows whether the field is volatile and already handles
the choice between "narrow" and "wide" volatile bitfields.

If there's talk of removing -fstrict-volatile or changing its semantics
then handling it in the interface ought to make that easier.

Richard

  reply	other threads:[~2012-11-15 12:25 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-03 11:10 [0/8] Add optabs alternatives for insv, extv and extzv Richard Sandiford
2012-11-03 11:13 ` [1/8] Handle TRUNCATE in make_extraction Richard Sandiford
2012-11-10 15:52   ` Eric Botcazou
2012-11-03 11:14 ` [2/8] Add adjust_bitfield_address_size Richard Sandiford
2012-11-10 15:53   ` Eric Botcazou
2012-11-03 11:16 ` [3/8] Add narrow_bit_field_mem Richard Sandiford
2012-11-10 16:02   ` Eric Botcazou
2012-11-03 11:21 ` [4/8] Add bit_field_mode_iterator Richard Sandiford
2012-11-13 12:44   ` Eric Botcazou
2012-11-13 21:46     ` Richard Henderson
2012-11-13 22:05       ` Eric Botcazou
2012-11-15 12:11         ` Richard Sandiford
2012-11-15 20:39           ` Richard Henderson
2012-11-18 17:34             ` Richard Sandiford
2012-11-18 17:36     ` Richard Sandiford
2012-11-03 11:27 ` [5/8] Tweak bitfield alignment handling Richard Sandiford
2012-11-13 13:52   ` Eric Botcazou
2012-11-18 17:36     ` Richard Sandiford
2012-11-20  2:57       ` John David Anglin
2012-11-20  8:21         ` Mikael Pettersson
2012-11-20 10:32           ` Richard Sandiford
2012-11-20 19:56             ` Richard Sandiford
2012-11-20 22:11             ` Eric Botcazou
2012-11-03 11:28 ` [6/8] Add strict volatile handling to bit_field_mode_iterator Richard Sandiford
2012-11-13 13:57   ` Eric Botcazou
2012-11-15 12:25     ` Richard Sandiford [this message]
2012-11-15 17:10       ` Eric Botcazou
2012-11-15 17:47         ` Richard Sandiford
2012-11-15 19:32           ` Eric Botcazou
2012-11-18 17:36             ` Richard Sandiford
2012-11-03 11:39 ` [7/8] Replace mode_for_extraction with new interface Richard Sandiford
2012-11-03 11:41 ` [8/8] Add new optabs and use them for MIPS Richard Sandiford
2012-11-27 17:11 ` [0/8] Add optabs alternatives for insv, extv and extzv Ramana Radhakrishnan
2012-11-27 20:22   ` Richard Sandiford
2012-11-27 22:45     ` Ramana Radhakrishnan
2012-11-28 10:25       ` Richard Biener
2012-11-28 12:06         ` Ramana Radhakrishnan
2012-11-28 12:51           ` Richard Biener
2012-11-28 13:58       ` Richard Sandiford
2012-11-28 23:19         ` Eric Botcazou
2012-11-29 10:31           ` Richard Sandiford
2012-11-29 15:31             ` Eric Botcazou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fw4bvyrv.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com \
    --to=rdsandiford@googlemail.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).