This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/16721] [3.5 Regression] Accesses to volatile objects optimized away


------- Additional Comments From macro at linux-mips dot org  2004-07-29 11:26 -------
(In reply to comment #8)

 Well, I've missed the section about standard conformance -- thanks for pointing
that out.  Anyway, the note about C in the C++ section hints about the expected
behavior of GCC for read accesses to volatile objects and I am pretty sure it's
actually what's widely expected by developers as well.  The use of the
"volatile" keyword is presently two-fold, specifically:

1. Marking objects referring to hardware that does not behave as plain memory.

2. Marking objects in ordinary memory that can change unexpectedly, e.g. by
   another CPU or by an interrupt handler.

For the latter eliminating dead reads is safe.  For the former it is not.  Thus
one could argue it would be beneficial to differentiate between the two cases,
e.g. by defining an additional variable attribute to enable or inhibit such
elimination.  I don't think it is really necessary -- the performance penalty
from a dead read from a memory variable is not that high and volatile objects
are special and require special attention from programmers anyway.  If there is
a possibility of a dead read to happen, then most likely it can be handled
explicitly with a conditional statement.  And older GCC versions used not to
optimize these reads away, so programmers should be prepared for the penalty
already.

 Therefore I propose to keep the old behavior and document it in the standard
conformance section to avoid confusion in the future.

-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]