This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/59190] New: atomic ops on a non-escaped variable don't need atomicity
- From: "glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 19 Nov 2013 14:56:07 +0000
- Subject: [Bug tree-optimization/59190] New: atomic ops on a non-escaped variable don't need atomicity
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59190
Bug ID: 59190
Summary: atomic ops on a non-escaped variable don't need
atomicity
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
#include <atomic>
int f(){
std::atomic_int i(0);
++i;
--i;
return i;
}
As in PR 48987, I would like to see this replaced by return 0 (and probably a
memory barrier), but for a different reason: no other thread can know about i,
so the operations don't need to be atomic. Once you make them regular
operations on an int, other optimizations should handle the rest.
Note that in my real use case, i is not an automatic variable, it is instead in
memory locally allocated by malloc, but that should still be doable.
The idea is to allow people to have a single type for global and local use and
still get the safety for one without losing too much speed for the other.