[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot com --- Comment #11 from frankhb1989 at gmail dot com --- I'd like to say it should be a bug, if I did not get it wrong. Even for a freestanding implementation, ISO C++11 explicitly specified as one of required header in table 16, and it should meet the same requirements as for a hosted implementation. Missing exception propagation is definitely not conforming, whether it can actually be implemented or not. Moreover, the standard doesn't specify anything about atomic operations on exception propagation, though it does requires that there should be no data race during some operations. Atomic operations here seem to be purely implementation details. Can it be implemented with something like __shared_ptr's lock policy? This issue also has effect on nested exceptions. Anyway, I feel something indeed wrong when I have to miss std::nested_exception for this reason on a platform which has even no multithreading support at all (as allowed by C++11). Sigh. BTW, libstdc++ manual Table 1.2 just tell me 'Y' for 18.8.5 and 18.8.6. Found no other notes about this issue. So at least it can be a defect of documentation.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 --- Comment #10 from Jonathan Wakely --- (In reply to Rafał Rawicki from comment #9) > I do link with libatomic.so - does that mean, I can patch this conditional > out (and similar conditional in the exception_ptr.h) and use exception_ptrs? You could try it. I don't know if it will work correctly. > Why it was decided to remove a part of standard library instead of enforcing > user to link with libatomic.so? That's the usual policy for the library, we don't define components that rely on features that are missing from target platforms.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 --- Comment #9 from Rafał Rawicki --- I'm sorry about my confusion of ATOMIC_INT_LOCK_FREE and _GLIBCXX_ATOMIC_BUILTINS meaning. In the meantime I've checked, when ATOMIC_INT_LOCK_FREE is defined as 2 and the target platform I have problems with (XScale, that is ARMv5), shouldn't have that defined. I'm still checking why I had _GLIBCXX_ATOMIC_BUILTINS_4 on gcc 4.6. I would like to have the same codebase on all platforms and I wouldn't like to stop using std::exception_ptr. Jonathan Wakely wrote, that without hardware support I need libatomic.so or I'd have an undefined behaviour. I do link with libatomic.so - does that mean, I can patch this conditional out (and similar conditional in the exception_ptr.h) and use exception_ptrs? Why it was decided to remove a part of standard library instead of enforcing user to link with libatomic.so?
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Paolo Carlini --- Closing then.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #7 from Andrew Macleod ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Rafał Rawicki from comment #3)
> > This is a regression, because a more specific _GLIBCXX_ATOMIC_BUILTINS_4 was
> > defined (but is no longer available) and now there is defined
> > ATOMIC_INT_LOCK_FREE=1 (I think think the definition is correct, because
> > there were available _GLIBCXX_ATOMIC_BUILTINS_{1,2,4} and no
> > _GLIBCXX_ATOMIC_BUILTINS_8).
>
> But ATOMIC_INT_LOCK_FREE only refers to int, i.e. 4-byte integer, so if
> _GLIBCXX_ATOMIC_BUILTINS_4 was defined then I would expect atomic ops on int
> to always be lock-free, i.e. the macro should be defined to 2. It's
> independent of whether atomic ops for 8-byte types are supported.
yes. if an integer_type_node is 4 bytes, and the architecture has a 4 byte
compare and swap, it should be set to 2 regardless of the lack of an 8 byte
lock free operation.
this assert should never fail:
if (__atomic_always_lock_free(4, NULL) && (sizeof(int) == 4))
assert (ATOMIC_INT_LOCK_FREE == 2);
In theory _GLIBCXX_ATOMIC_BUILTINS_4 should have been the same as
ATOMIC_INT_LOCK_FREE as long as sizeof (int) == 4
>
> > The other thing is, std::exception_ptr availability should not depend on the
> > fact whether the platform has lock-free atomics or not.
>
> Without them you either need libatomic.so or you risk undefined behaviour
> such as leaking exception objects or worse, dangling references to
> destroyed exceptions.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #6 from Jonathan Wakely ---
(In reply to Rafał Rawicki from comment #3)
> This is a regression, because a more specific _GLIBCXX_ATOMIC_BUILTINS_4 was
> defined (but is no longer available) and now there is defined
> ATOMIC_INT_LOCK_FREE=1 (I think think the definition is correct, because
> there were available _GLIBCXX_ATOMIC_BUILTINS_{1,2,4} and no
> _GLIBCXX_ATOMIC_BUILTINS_8).
But ATOMIC_INT_LOCK_FREE only refers to int, i.e. 4-byte integer, so if
_GLIBCXX_ATOMIC_BUILTINS_4 was defined then I would expect atomic ops on int to
always be lock-free, i.e. the macro should be defined to 2. It's independent
of whether atomic ops for 8-byte types are supported.
> The other thing is, std::exception_ptr availability should not depend on the
> fact whether the platform has lock-free atomics or not.
Without them you either need libatomic.so or you risk undefined behaviour such
as leaking exception objects or worse, dangling references to destroyed
exceptions.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 Paolo Carlini changed: What|Removed |Added CC|rafal at rawicki dot org |amacleod at redhat dot com --- Comment #5 from Paolo Carlini --- This is the relevant thread: http://gcc.gnu.org/ml/libstdc++/2011-11/msg00192.html Let's add Andrew in CC.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #4 from Rafał Rawicki ---
(In reply to Rafał Rawicki from comment #3)
> This is a regression, because a more specific _GLIBCXX_ATOMIC_BUILTINS_4 was
> defined (but is no longer available) and now there is defined
> ATOMIC_INT_LOCK_FREE=1 (I think think the definition is correct, because
> there were available _GLIBCXX_ATOMIC_BUILTINS_{1,2,4} and no
> _GLIBCXX_ATOMIC_BUILTINS_8).
>
> The other thing is, std::exception_ptr availability should not depend on the
> fact whether the platform has lock-free atomics or not.
s/_GLIBCXX_ATOMIC_BUILTINS_4 was defined/_GLIBCXX_ATOMIC_BUILTINS_4 was used/
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
Rafał Rawicki changed:
What|Removed |Added
CC||rafal at rawicki dot org
--- Comment #3 from Rafał Rawicki ---
This is a regression, because a more specific _GLIBCXX_ATOMIC_BUILTINS_4 was
defined (but is no longer available) and now there is defined
ATOMIC_INT_LOCK_FREE=1 (I think think the definition is correct, because there
were available _GLIBCXX_ATOMIC_BUILTINS_{1,2,4} and no
_GLIBCXX_ATOMIC_BUILTINS_8).
The other thing is, std::exception_ptr availability should not depend on the
fact whether the platform has lock-free atomics or not.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 --- Comment #2 from Jonathan Wakely --- So why is this a regression? Does ARM define _GLIBCXX_ATOMIC_BUILTINS_4 but ATOMIC_INT_LOCK_FREE=1 ? That seems like a bug in those definitions.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 Paolo Carlini changed: What|Removed |Added CC||jwakely.gcc at gmail dot com --- Comment #1 from Paolo Carlini --- Was included conditionally before r181869 too, but the condition was different, checked _GLIBCXX_ATOMIC_BUILTINS_4 instead of ATOMIC_INT_LOCK_FREE > 1.
