public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "macro at linux-mips dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/16721] [3.5 Regression] Accesses to volatile objects optimized away Date: Tue, 27 Jul 2004 12:50:00 -0000 [thread overview] Message-ID: <20040727125037.14433.qmail@sourceware.org> (raw) In-Reply-To: <20040726181156.16721.macro@linux-mips.org> ------- Additional Comments From macro at linux-mips dot org 2004-07-27 12:50 ------- (In reply to comment #3) `info "(gcc)"Volatiles' disagrees -- despite it being mostly about C++, it refers to GCC's behavior for C code, too. Specifically: "[...] Less obvious expressions are where something which looks like an access is used in a void context. An example would be, volatile int *src = SOMEVALUE; *src; With C, such expressions are rvalues, and as rvalues cause a read of the object, GCC interprets this as a read of the volatile being pointed to. [...]" Otherwise, what is your proposal about coding reads that must not be optimized away due to side effects they have? The reads missing from Linux binaries due to this bug are accesses to a DMA controller register to reset the logic at the end of a transfer. This is the lone need for them in this context -- the value read is not needed there for anything. There are more cases like this -- it's just that this one was the first one I've spotted, and actually quite a critical one as the DMA controller is used for CoW by the paging subsystem on this platform. Others may stay hidden as the may only trigger under less common circumstances only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16721
next prev parent reply other threads:[~2004-07-27 12:50 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-07-26 18:12 [Bug c/16721] New: Accesses to volatile objects optimized away with -fno-strict-aliasing gcc-bugzilla at gcc dot gnu dot org 2004-07-26 19:04 ` [Bug c/16721] [3.5 Regression] Accesses to volatile objects optimized away falk at debian dot org 2004-07-26 19:24 ` pinskia at gcc dot gnu dot org 2004-07-26 19:30 ` falk at debian dot org 2004-07-27 12:25 ` macro at linux-mips dot org 2004-07-27 12:50 ` macro at linux-mips dot org [this message] 2004-07-27 14:48 ` falk at debian dot org 2004-07-29 2:33 ` [Bug tree-optimization/16721] " pinskia at gcc dot gnu dot org 2004-07-29 11:27 ` macro at linux-mips dot org 2004-08-03 5:58 ` pinskia at gcc dot gnu dot org 2004-09-19 13:57 ` [Bug tree-optimization/16721] [4.0 " steven at gcc dot gnu dot org 2004-09-19 15:42 ` bangerth at dealii dot org 2004-09-22 14:41 ` dnovillo at gcc dot gnu dot org 2004-09-22 16:14 ` dnovillo at gcc dot gnu dot org 2004-09-22 16:26 ` stevenb at suse dot de 2004-09-22 16:41 ` dnovillo at redhat dot com 2004-09-22 17:23 ` dnovillo at gcc dot gnu dot org 2004-09-22 17:23 ` dnovillo at gcc dot gnu dot org 2004-09-22 23:33 ` cvs-commit at gcc dot gnu dot org 2004-09-22 23:36 ` dnovillo at gcc dot gnu dot org
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=20040727125037.14433.qmail@sourceware.org \ --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).