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


  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: 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).