public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/65449] -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes
Date: Thu, 19 Mar 2015 14:33:00 -0000	[thread overview]
Message-ID: <bug-65449-4-6tjwgumRMt@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65449-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Yes, but that is not the fault of the strict volatile code path any more.

For bit-fields this redundant read is exactly what AAPCS demands:

"7.1.7.5 Volatile bit - fields preserving number and width of container
accesses

When a volatile bit-field is read, its container must be read exactly
once using the access width appropriate to the type of the container.

When a volatile bit-field is written, its container must be read exactly
once and written exactly once using the access width appropriate to the
type of the container. The two accesses are not atomic."


IMO, the problem is this:

In store_fixed_bit_field_1 we do not know if the access is on a
packed structure member where the extra read is not necessary,
or if we have a bit-field where the extra read would be mandatory,
even if the complete container is overwritten.


BTW: What happens in your example if you use -O0? Isn't there still an
unaligned stw access?  That's because you example is in a way invalid C.
You can't set an int* to an unaligned address, it must be at least
aligned to the GET_MODE_ALIGNMENT(SImode).


  parent reply	other threads:[~2015-03-19 13:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17  9:28 [Bug middle-end/65449] New: " ma.jiang at zte dot com.cn
2015-03-18 12:12 ` [Bug middle-end/65449] " bernd.edlinger at hotmail dot de
2015-03-19 10:03 ` ma.jiang at zte dot com.cn
2015-03-19 14:33 ` bernd.edlinger at hotmail dot de [this message]
2015-03-20  5:14 ` ma.jiang at zte dot com.cn

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=bug-65449-4-6tjwgumRMt@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).