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).
next prev 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: linkBe 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).