[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #8 from Jonathan Wakely --- The C++17 standard says that arithmetic on atomic pointer types is ill-formed, so libstdc++ now enforces that for C++17 and later.
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Thu May 24 15:28:26 2018 New Revision: 260676 URL: https://gcc.gnu.org/viewcvs?rev=260676=gcc=rev Log: Implement P0558R2 changes to std::atomic The restrictions forbidding arithmetic on atomic pointer types are only enabled for C++17 and later, retaining the GNU extension for older standards. The new nested typedefs and changes to prevent scalar parameters participating in template argument deduction are enabled unconditionally. PR libstdc++/69769 PR libstdc++/85886 * include/bits/atomic_base.h (__atomic_base::value_type) (__atomic_base::difference_type): Add new typedefs. * include/std/atomic (atomic::value_type, atomic::value_type) (atomic::value_type, atomic ::difference_type): Likewise. (atomic ::operator++, atomic ::operator--) (atomic ::operator+=, atomic ::operator-=) (atomic ::fetch_add, atomic ::fetch_sub): Add static assertion to enforce C++17 requirement on pointer arithmetic. (__atomic_val_t, __atomic_diff_t): New alias templates. (atomic_init, atomic_store_explicit, atomic_exchange_explicit) (atomic_compare_exchange_weak_explicit) (atomic_compare_exchange_strong_explicit, atomic_store) (atomic_exchange, atomic_compare_exchange_weak) (atomic_compare_exchange_strong): Use __atomic_val_t to make scalar parameters be non-deduced contexts. (atomic_fetch_add_explicit, atomic_fetch_sub_explicit) (atomic_fetch_add, atomic_fetch_sub): Change first parameter to be atomic instead of __atomic_base, and use __atomic_diff_t for scalar parameters. (atomic_fetch_and_explicit, atomic_fetch_or_explicit) (atomic_fetch_xor_explicit, atomic_fetch_and, atomic_fetch_or) (atomic_fetch_xor): Use __atomic_val_t for scalar parameters. (atomic_fetch_add_explicit, atomic_fetch_sub_explicit) (atomic_fetch_add, atomic_fetch_sub): Remove overloads for atomic address types. * testsuite/29_atomics/atomic/60695.cc: Adjust dg-error lineno. * testsuite/29_atomics/atomic/69769.cc: New test. * testsuite/29_atomics/atomic/nonmembers.cc: New test. * testsuite/29_atomics/atomic/operators/pointer_partial_void.cc: Disable test for C++17 and later. * testsuite/29_atomics/atomic/requirements/typedefs.cc: New test. * testsuite/29_atomics/atomic_integral/nonmembers.cc: New test. * testsuite/29_atomics/atomic_integral/requirements/typedefs.cc: New test. Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic/69769.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic/nonmembers.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic/requirements/typedefs.cc - copied, changed from r260635, trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/nonmembers.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic_integral/requirements/typedefs.cc - copied, changed from r260635, trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_base.h trunk/libstdc++-v3/include/std/atomic trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc trunk/libstdc++-v3/testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 --- Comment #6 from Jonathan Wakely --- (In reply to Wolfgang Roehrl from comment #0) > The compiler accepts this programm despite of performing an arithmetic > operation on pointer to a function. Arithmetic on (non-atomic) function pointers is supported by GCC: https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html So this is consistent with the built-in types.
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-18 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- P0558R1 added the following to the atomicspecialization: Requires: T shall be an object type, otherwise the program is ill-formed. [Note: Pointer arithmetic on void* or function pointers is ill-formed. — end note ]
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 --- Comment #4 from Jonathan Wakely --- For atomicClang rejects use of its builtin with a void*: /usr/local/libcxx-head/include/c++/v1/atomic:1081:40: error: incomplete type 'void' where a complete type is required But it allows the function pointer case. Arguably it makes sense for __atomic_fetch_add etc. to do the checking, although the fact that GCC does allow arithmetic on void* complicates that.
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 --- Comment #3 from Jonathan Wakely --- The same problem exists for std::atomic
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 --- Comment #2 from Jonathan Wakely --- No, I'm not aware of one.
[Bug libstdc++/69769] arithmetic operation on pointer to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69769 Martin Sebor changed: What|Removed |Added CC||jwakely.gcc at gmail dot com, ||msebor at gcc dot gnu.org Component|c++ |libstdc++ --- Comment #1 from Martin Sebor --- The header is part of libstdc++ so setting Component to it. I agree that this should be rejected but I'm not sure that this isn't actually a defect in the standard. AFAICS, the partial specializations of atomic for pointers don't say that function pointers should be treated differently than object pointers. Jonathan, is there an issue on this (I may have overlooked int)?