This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[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
- From: "zsojka at seznam dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 16 Feb 2012 20:14:54 +0000
- 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
- Auto-submitted: auto-generated
- References: <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