--- Comment #10 from joseph dot h dot garvin at gmail dot com 2009-06-08
21:18 ---
After encountering this issue and some testing, I think this is definitely a
bug. The problem ONLY occurs when directly returning a call to an atomic
builtin! Assuming no march flags:
Links:
int main
: joseph dot h dot garvin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40562
--- Comment #1 from joseph dot h dot garvin at gmail dot com 2009-06-26
20:01 ---
Actually, make that 4 bugs.
4. The extension shouldn't matter. I said run the preprocessor on it. So run
the preprocessor on it.
G++ is bending over backwards to do the wrong thing :P
--
http
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joseph dot h dot garvin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42322
--- Comment #15 from joseph dot h dot garvin at gmail dot com 2010-01-21
18:38 ---
I'm not sure what the standard says, but conceptually, if you only provide a
template generic template foo, with no non-templated foo defined, then
instantiations of foo are *never* 'overloaded.' If I
names
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joseph dot h dot garvin at gmail dot com
http
--- Comment #5 from joseph dot h dot garvin at gmail dot com 2010-04-09
21:06 ---
As a separate affected user, might I ask you guys to reconsider again? If
you're writing a smart pointer class in C++, users expect that you will support
all the same operators with all the same semantics
--- Comment #7 from joseph dot h dot garvin at gmail dot com 2010-04-12
12:19 ---
Right, I think that's what users expect, assuming you are in a situation where
volatile smart pointers make sense in the first place (in my case they are
smart pointers to addresses within a shared memory
--- Comment #9 from joseph dot h dot garvin at gmail dot com 2010-04-12
15:00 ---
(In reply to comment #8)
(In reply to comment #7)
the former points to an object which might change due to effects outside the
program, the latter implies that the smart pointer itself might change
ReportedBy: joseph dot h dot garvin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45168
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joseph dot h dot garvin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45615
11 matches
Mail list logo
