public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "zsojka at seznam dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
Date: Thu, 16 Feb 2012 20:59:00 -0000	[thread overview]
Message-ID: <bug-45472-4-LPfUzbqZoz@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-45472-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472

--- Comment #20 from Zdenek Sojka <zsojka at seznam dot cz> 2012-02-16 20:14:54 UTC ---
I can think of two use-cases from threaded environment:
- using the volatile member as a semaphore for the structure
- when one needs to assure some data will be written in certain order (eg.
first write data, then the 'data valid' flag), while other members of the
structure don't need to be volatile (data used by only one thread, or data that
are only read; marking the whole struct volatile would prevent some
optimisations)

Other cases:
- when debugging and you want to prevent optimisations of certain variable
- when the structure is allocated on a memory-mapped IO address, and only some
parts of that IO need to be marked as volatile
- in OOP, where the variable is a member, and would otherwise be a global
volatile variable


  parent reply	other threads:[~2012-02-16 20:52 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-45472-4@http.gcc.gnu.org/bugzilla/>
2010-10-18 10:57 ` [Bug rtl-optimization/45472] [4.5/4.6 Regression] " abel at gcc dot gnu.org
2010-10-18 11:47 ` matz at gcc dot gnu.org
2010-10-18 12:21 ` bonzini at gnu dot org
2010-10-18 15:43 ` rguenth at gcc dot gnu.org
2010-10-18 15:58 ` matz at gcc dot gnu.org
2010-10-18 16:41 ` joseph at codesourcery dot com
2010-10-18 17:13 ` bonzini at gnu dot org
2010-12-16 13:09 ` rguenth at gcc dot gnu.org
2011-01-13 10:35 ` abel at gcc dot gnu.org
2011-04-08  6:42 ` [Bug middle-end/45472] [4.5/4.6/4.7 " abel at gcc dot gnu.org
2011-04-28 15:08 ` rguenth at gcc dot gnu.org
2011-12-10  5:52 ` pinskia at gcc dot gnu.org
2012-01-19  9:38 ` abel at gcc dot gnu.org
2012-02-16 19:52 ` [Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] " jason at gcc dot gnu.org
2012-02-16 20:59 ` zsojka at seznam dot cz [this message]
2012-02-20 11:55 ` rguenth at gcc dot gnu.org
2012-02-27  9:18 ` ebotcazou at gcc dot gnu.org
2012-07-02 11:20 ` [Bug middle-end/45472] [4.5/4.6/4.7/4.8 " rguenth at gcc dot gnu.org
2013-01-05 21:12 ` [Bug middle-end/45472] [4.6/4.7/4.8 " dje at gcc dot gnu.org
2013-01-05 21:44 ` zsojka at seznam dot cz
2013-02-26  9:22 ` abel at gcc dot gnu.org
2013-02-27  8:56 ` abel at gcc dot gnu.org
2013-02-27  9:04 ` [Bug middle-end/45472] [4.6/4.7 " abel at gcc dot gnu.org
2013-04-03  6:00 ` abel at gcc dot gnu.org
2013-04-12 15:16 ` [Bug middle-end/45472] [4.7 " jakub at gcc dot gnu.org
2014-06-12 12:58 ` rguenth at gcc dot gnu.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=bug-45472-4-LPfUzbqZoz@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).