Deprecating arithmetic on std::atomic<void*>

Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

I know it's a bit late, but I'd like to propose deprecating the
libstdc++ extension that allows arithmetic on std::atomic<void*>.
Currently we make it behave like arithmetic on void*, which is also a
GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
We also allow arithmetic on types such as std::atomic<void(*)()> which
is probably not useful (PR 69769).

C++11 and C++14 were silent on the matter, but C++17 makes it
explicitly ill-formed (see https://wg21.link/p0558r1 page 2). I'm
implementing that for C++17 mode but would like it to be ill-formed
for all modes in a future release.

So I'd like to apply this patch to the gcc-7/changes.html page:

--- htdocs/gcc-7/changes.html   17 Apr 2017 22:12:35 -0000      1.77                                                                                                                                              
+++ htdocs/gcc-7/changes.html   19 Apr 2017 17:05:27 -0000                                                                                                                                                        
@@ -38,6 +38,10 @@
   </li>
 
   <li>The Cilk+ extensions to the C and C++ languages have been deprecated.</li>
+
+  <li>The extension allowing arithmetic on <code>std::atomic&lt;void*&gt;</code>
+      and types like <code>std::atomic&lt;R(*)()&gt;</code>
+      has been deprecated.</li>
 </ul>
 
 <!-- .................................................................. -->


Does this seem reasonable, or do people think we need to keep this
feature, to match the core language extensions?

Re: Deprecating arithmetic on std::atomic<void*>

[Ville Voutilainen]

On 19 April 2017 at 20:07, Jonathan Wakely <jwakely@redhat.com> wrote:
> I know it's a bit late, but I'd like to propose deprecating the
> libstdc++ extension that allows arithmetic on std::atomic<void*>.
> Currently we make it behave like arithmetic on void*, which is also a
> GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
> We also allow arithmetic on types such as std::atomic<void(*)()> which
> is probably not useful (PR 69769).
>
> C++11 and C++14 were silent on the matter, but C++17 makes it
> explicitly ill-formed (see https://wg21.link/p0558r1 page 2). I'm
> implementing that for C++17 mode but would like it to be ill-formed
> for all modes in a future release.
>
> So I'd like to apply this patch to the gcc-7/changes.html page:
>
> --- htdocs/gcc-7/changes.html   17 Apr 2017 22:12:35 -0000      1.77
> +++ htdocs/gcc-7/changes.html   19 Apr 2017 17:05:27 -0000
> @@ -38,6 +38,10 @@
>   </li>
>
>   <li>The Cilk+ extensions to the C and C++ languages have been
> deprecated.</li>
> +
> +  <li>The extension allowing arithmetic on
> <code>std::atomic&lt;void*&gt;</code>
> +      and types like <code>std::atomic&lt;R(*)()&gt;</code>
> +      has been deprecated.</li>
> </ul>
>
> <!-- .................................................................. -->
>
>
> Does this seem reasonable, or do people think we need to keep this
> feature, to match the core language extensions?
>

I think it's reasonable. If users report massive concerns, we can
certainly un-deprecate it.
At the moment all that deprecation is doing for non-C++17 modes is
giving users a fair warning
of things to be aware of, and we can get feedback on that.

Re: Deprecating arithmetic on std::atomic<void*>

[Florian Weimer]

On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
> I know it's a bit late, but I'd like to propose deprecating the
> libstdc++ extension that allows arithmetic on std::atomic<void*>.
> Currently we make it behave like arithmetic on void*, which is also a
> GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
> We also allow arithmetic on types such as std::atomic<void(*)()> which
> is probably not useful (PR 69769).

Why is it acceptable to have the extension for built-in types, but not 
for library types wrapping them?  Why be inconsistent about this?

Thanks,
Florian

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 08:19 +0200, Florian Weimer wrote:
>On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>>I know it's a bit late, but I'd like to propose deprecating the
>>libstdc++ extension that allows arithmetic on std::atomic<void*>.
>>Currently we make it behave like arithmetic on void*, which is also a
>>GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>>We also allow arithmetic on types such as std::atomic<void(*)()> which
>>is probably not useful (PR 69769).
>
>Why is it acceptable to have the extension for built-in types, but not 
>for library types wrapping them?  Why be inconsistent about this?

C++17 [atomic.types.pointer] paragraph 4 says:

  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]

That doesn't give us any leeway to support it.

Personally I'd be in favour of removing the extension for built-in
types too, but I doubt that would get consensus :-)

Re: Deprecating arithmetic on std::atomic<void*>

[Jakub Jelinek]

On Thu, Apr 20, 2017 at 10:18:09AM +0100, Jonathan Wakely wrote:
> On 20/04/17 08:19 +0200, Florian Weimer wrote:
> > On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
> > > I know it's a bit late, but I'd like to propose deprecating the
> > > libstdc++ extension that allows arithmetic on std::atomic<void*>.
> > > Currently we make it behave like arithmetic on void*, which is also a
> > > GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
> > > We also allow arithmetic on types such as std::atomic<void(*)()> which
> > > is probably not useful (PR 69769).
> > 
> > Why is it acceptable to have the extension for built-in types, but not
> > for library types wrapping them?  Why be inconsistent about this?
> 
> C++17 [atomic.types.pointer] paragraph 4 says:
> 
>  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]
> 
> That doesn't give us any leeway to support it.

Can't the support or lack thereof depend on -pedantic/-pedantic-errors?
I mean, with -pedantic-errors we already error on void * arighmetics
or function pointer arithmetics.  If std::atomic<void*> would use
the void * arithmetics, it would also reject it.  Or does it use integer
arithmetics instead?

	Jakub

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 11:21 +0200, Jakub Jelinek wrote:
>On Thu, Apr 20, 2017 at 10:18:09AM +0100, Jonathan Wakely wrote:
>> On 20/04/17 08:19 +0200, Florian Weimer wrote:
>> > On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>> > > I know it's a bit late, but I'd like to propose deprecating the
>> > > libstdc++ extension that allows arithmetic on std::atomic<void*>.
>> > > Currently we make it behave like arithmetic on void*, which is also a
>> > > GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>> > > We also allow arithmetic on types such as std::atomic<void(*)()> which
>> > > is probably not useful (PR 69769).
>> >
>> > Why is it acceptable to have the extension for built-in types, but not
>> > for library types wrapping them?  Why be inconsistent about this?
>>
>> C++17 [atomic.types.pointer] paragraph 4 says:
>>
>>  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]
>>
>> That doesn't give us any leeway to support it.
>
>Can't the support or lack thereof depend on -pedantic/-pedantic-errors?

In theory maybe.

>I mean, with -pedantic-errors we already error on void * arighmetics
>or function pointer arithmetics.  If std::atomic<void*> would use
>the void * arithmetics, it would also reject it.  Or does it use integer
>arithmetics instead?

No, it does it on void*, but the __atomic built-ins still perform that
arithmetic even with -pedantic-errors.

Re: Deprecating arithmetic on std::atomic<void*>

[Jakub Jelinek]

On Thu, Apr 20, 2017 at 10:25:40AM +0100, Jonathan Wakely wrote:
> In theory maybe.
> 
> > I mean, with -pedantic-errors we already error on void * arighmetics
> > or function pointer arithmetics.  If std::atomic<void*> would use
> > the void * arithmetics, it would also reject it.  Or does it use integer
> > arithmetics instead?
> 
> No, it does it on void*, but the __atomic built-ins still perform that
> arithmetic even with -pedantic-errors.

Maybe that is what we should change, i.e. issue pedwarns similar to what we
emit on void * normal arithmetics for atomic/sync builtins that perform
arithmetics on void *, and error? for function pointer arithmetics.

	Jakub

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 10:25 +0100, Jonathan Wakely wrote:
>On 20/04/17 11:21 +0200, Jakub Jelinek wrote:
>>On Thu, Apr 20, 2017 at 10:18:09AM +0100, Jonathan Wakely wrote:
>>>On 20/04/17 08:19 +0200, Florian Weimer wrote:
>>>> On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>>>> > I know it's a bit late, but I'd like to propose deprecating the
>>>> > libstdc++ extension that allows arithmetic on std::atomic<void*>.
>>>> > Currently we make it behave like arithmetic on void*, which is also a
>>>> > GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>>>> > We also allow arithmetic on types such as std::atomic<void(*)()> which
>>>> > is probably not useful (PR 69769).
>>>>
>>>> Why is it acceptable to have the extension for built-in types, but not
>>>> for library types wrapping them?  Why be inconsistent about this?
>>>
>>>C++17 [atomic.types.pointer] paragraph 4 says:
>>>
>>> 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]
>>>
>>>That doesn't give us any leeway to support it.
>>
>>Can't the support or lack thereof depend on -pedantic/-pedantic-errors?
>
>In theory maybe.
>
>>I mean, with -pedantic-errors we already error on void * arighmetics
>>or function pointer arithmetics.  If std::atomic<void*> would use
>>the void * arithmetics, it would also reject it.  Or does it use integer
>>arithmetics instead?
>
>No, it does it on void*, but the __atomic built-ins still perform that
>arithmetic even with -pedantic-errors.


If we can make the built-ins do the right thing then I'd be happy with
that.

However, currently the built-ins treat all pointer arithmetic as void*
(or maybe char*, I'm not sure) i.e. arithmetic on T* ignores
sizeof(T). We already work around this in libstdc++, and PR 64843
points out <stdatomic.h> needs to do the same.

Re: Deprecating arithmetic on std::atomic<void*>

[Florian Weimer]

On 04/20/2017 11:25 AM, Jonathan Wakely wrote:

>> I mean, with -pedantic-errors we already error on void * arighmetics
>> or function pointer arithmetics.  If std::atomic<void*> would use
>> the void * arithmetics, it would also reject it.  Or does it use integer
>> arithmetics instead?
> 
> No, it does it on void*, but the __atomic built-ins still perform that
> arithmetic even with -pedantic-errors.

sizeof is not defined for the relevant types, either, and already 
triggers a warning by default:

t.cc:25:58: warning: invalid application of ‘sizeof’ to a void type 
[-Wpointer-arith]
    _M_type_size(ptrdiff_t __d) const { return __d * sizeof(_PTp); }

I think the actual problem here is the suppression of warnings from 
system headers.

Florian

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 11:43 +0200, Florian Weimer wrote:
>On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
>
>>>I mean, with -pedantic-errors we already error on void * arighmetics
>>>or function pointer arithmetics.  If std::atomic<void*> would use
>>>the void * arithmetics, it would also reject it.  Or does it use integer
>>>arithmetics instead?
>>
>>No, it does it on void*, but the __atomic built-ins still perform that
>>arithmetic even with -pedantic-errors.
>
>sizeof is not defined for the relevant types, either, and already 
>triggers a warning by default:
>
>t.cc:25:58: warning: invalid application of ‘sizeof’ to a void type 
>[-Wpointer-arith]
>   _M_type_size(ptrdiff_t __d) const { return __d * sizeof(_PTp); }

That could be easily avoided if we care about supporting arithmetic on
std::atomic<void*>.

>I think the actual problem here is the suppression of warnings from 
>system headers.

The atomic built-ins still don't warn even with -Wsystem-headers

Re: Deprecating arithmetic on std::atomic<void*>

[Florian Weimer]

On 04/20/2017 11:52 AM, Jonathan Wakely wrote:
> On 20/04/17 11:43 +0200, Florian Weimer wrote:
>> On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
>>
>>>> I mean, with -pedantic-errors we already error on void * arighmetics
>>>> or function pointer arithmetics.  If std::atomic<void*> would use
>>>> the void * arithmetics, it would also reject it.  Or does it use 
>>>> integer
>>>> arithmetics instead?
>>>
>>> No, it does it on void*, but the __atomic built-ins still perform that
>>> arithmetic even with -pedantic-errors.
>>
>> sizeof is not defined for the relevant types, either, and already 
>> triggers a warning by default:
>>
>> t.cc:25:58: warning: invalid application of ‘sizeof’ to a void type 
>> [-Wpointer-arith]
>>   _M_type_size(ptrdiff_t __d) const { return __d * sizeof(_PTp); }
> 
> That could be easily avoided if we care about supporting arithmetic on
> std::atomic<void*>.
> 
>> I think the actual problem here is the suppression of warnings from 
>> system headers.
> 
> The atomic built-ins still don't warn even with -Wsystem-headers

Sorry, this is what I meant: -pedantic-errors does not catch this case 
due to the system header warning suppression.  Otherwise, with the 
current std::atomic implementation, -pedantic-errors would already 
disable the extension on std::atomic alongside with the extension on 
built-in pointer types, due to the use of sizeof in the definition of 
_M_type_size.

Thanks,
Florian

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 11:57 +0200, Florian Weimer wrote:
>On 04/20/2017 11:52 AM, Jonathan Wakely wrote:
>>On 20/04/17 11:43 +0200, Florian Weimer wrote:
>>>On 04/20/2017 11:25 AM, Jonathan Wakely wrote:
>>>
>>>>>I mean, with -pedantic-errors we already error on void * arighmetics
>>>>>or function pointer arithmetics.  If std::atomic<void*> would use
>>>>>the void * arithmetics, it would also reject it.  Or does it 
>>>>>use integer
>>>>>arithmetics instead?
>>>>
>>>>No, it does it on void*, but the __atomic built-ins still perform that
>>>>arithmetic even with -pedantic-errors.
>>>
>>>sizeof is not defined for the relevant types, either, and already 
>>>triggers a warning by default:
>>>
>>>t.cc:25:58: warning: invalid application of ‘sizeof’ to a void 
>>>type [-Wpointer-arith]
>>>  _M_type_size(ptrdiff_t __d) const { return __d * sizeof(_PTp); }
>>
>>That could be easily avoided if we care about supporting arithmetic on
>>std::atomic<void*>.
>>
>>>I think the actual problem here is the suppression of warnings 
>>>from system headers.
>>
>>The atomic built-ins still don't warn even with -Wsystem-headers
>
>Sorry, this is what I meant: -pedantic-errors does not catch this case 
>due to the system header warning suppression.  Otherwise, with the 
>current std::atomic implementation, -pedantic-errors would already 
>disable the extension on std::atomic alongside with the extension on 
>built-in pointer types, due to the use of sizeof in the definition of 
>_M_type_size.

Ah yes, you're right.

Yet another case where warning suppression in system headers hurts the
library's ability to give diagnostics. We can't warn about using
incomplete types in std::unique_ptr because the -Wdelete-incomplete
warning gets suppressed, and the interaction of #pragma GCC diagnostic
with -Wsystem-headers is ... interesting. We need a way to enable
warnings for specific blocks of code, to say "do not suppress warnings
here, even though it's in a system header".

Re: Deprecating arithmetic on std::atomic<void*>

[Jakub Jelinek]

On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
> Yet another case where warning suppression in system headers hurts the
> library's ability to give diagnostics. We can't warn about using
> incomplete types in std::unique_ptr because the -Wdelete-incomplete
> warning gets suppressed, and the interaction of #pragma GCC diagnostic
> with -Wsystem-headers is ... interesting. We need a way to enable
> warnings for specific blocks of code, to say "do not suppress warnings
> here, even though it's in a system header".

Can #pragma GCC warning "-Wno-system-headers" do that?

	Jakub

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 12:07 +0200, Jakub Jelinek wrote:
>On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
>> Yet another case where warning suppression in system headers hurts the
>> library's ability to give diagnostics. We can't warn about using
>> incomplete types in std::unique_ptr because the -Wdelete-incomplete
>> warning gets suppressed, and the interaction of #pragma GCC diagnostic
>> with -Wsystem-headers is ... interesting. We need a way to enable
>> warnings for specific blocks of code, to say "do not suppress warnings
>> here, even though it's in a system header".
>
>Can #pragma GCC warning "-Wno-system-headers" do that?

I don't think so. It didn't work last time I tried to use that to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876

I don't remember the details, but I think there was some weirdness
like the "pop" didn't restore the old value, or some other class of
warning disappeaed.

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 11:12 +0100, Jonathan Wakely wrote:
>On 20/04/17 12:07 +0200, Jakub Jelinek wrote:
>>On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
>>>Yet another case where warning suppression in system headers hurts the
>>>library's ability to give diagnostics. We can't warn about using
>>>incomplete types in std::unique_ptr because the -Wdelete-incomplete
>>>warning gets suppressed, and the interaction of #pragma GCC diagnostic
>>>with -Wsystem-headers is ... interesting. We need a way to enable
>>>warnings for specific blocks of code, to say "do not suppress warnings
>>>here, even though it's in a system header".
>>
>>Can #pragma GCC warning "-Wno-system-headers" do that?
>
>I don't think so. It didn't work last time I tried to use that to fix
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
>
>I don't remember the details, but I think there was some weirdness
>like the "pop" didn't restore the old value, or some other class of
>warning disappeaed.


I might be misremembering. I thought I'd found a problem with that
approach, but I can't find any evidence of what the problem was. I
have an old draft email from October 2013 with the text below. Maybe I
just never committed it due to moving jobs at the time.

===
I'm inclined to commit this patch to locally enable -Wsystem-headers
around default_delete and the _Sp_counter_ptr manager used by
shared_ptr.

This would ensure we don't suppress "deleting object of abstract type
without virtual destructor will cause undefined behaviour" errors when
giving ownership of such a pointer to shared_ptr or unique_ptr.

The downside is that users have to use -Wno-delete-non-virtual-dtor to
suppress the warning again if they really don't want it, but I think
that's good. This is a real error in user code, the only reason we
don't already warn is that the error happens in a template defined in
a system header.

We could similar thing in other places too, e.g. disable
-Wpointer-arith around __atomic_base which relies on this extension
for __atomic_base<cv void*>
http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
===

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 12:20 +0100, Jonathan Wakely wrote:
>On 20/04/17 11:12 +0100, Jonathan Wakely wrote:
>>On 20/04/17 12:07 +0200, Jakub Jelinek wrote:
>>>On Thu, Apr 20, 2017 at 11:03:38AM +0100, Jonathan Wakely wrote:
>>>>Yet another case where warning suppression in system headers hurts the
>>>>library's ability to give diagnostics. We can't warn about using
>>>>incomplete types in std::unique_ptr because the -Wdelete-incomplete
>>>>warning gets suppressed, and the interaction of #pragma GCC diagnostic
>>>>with -Wsystem-headers is ... interesting. We need a way to enable
>>>>warnings for specific blocks of code, to say "do not suppress warnings
>>>>here, even though it's in a system header".
>>>
>>>Can #pragma GCC warning "-Wno-system-headers" do that?
>>
>>I don't think so. It didn't work last time I tried to use that to fix
>>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
>>
>>I don't remember the details, but I think there was some weirdness
>>like the "pop" didn't restore the old value, or some other class of
>>warning disappeaed.
>
>
>I might be misremembering. I thought I'd found a problem with that
>approach, but I can't find any evidence of what the problem was.

I was right, push/pop doesn't work for -Wsystem-headers:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692#c2

My attempted fix for 58876 causes a cascade of other warnings because
-Wsystem-headers remains active (and PR 79078 makes auto_ptr warn
about itself!)

I opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80472

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
>On 20/04/17 08:19 +0200, Florian Weimer wrote:
>>On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>>>I know it's a bit late, but I'd like to propose deprecating the
>>>libstdc++ extension that allows arithmetic on std::atomic<void*>.
>>>Currently we make it behave like arithmetic on void*, which is also a
>>>GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>>>We also allow arithmetic on types such as std::atomic<void(*)()> which
>>>is probably not useful (PR 69769).
>>
>>Why is it acceptable to have the extension for built-in types, but 
>>not for library types wrapping them?  Why be inconsistent about 
>>this?
>
>C++17 [atomic.types.pointer] paragraph 4 says:
>
> 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]
>
>That doesn't give us any leeway to support it.

I suppose we could support it without -Wpedantic, although there's no
way for the library to know if the front-end is being pedantic or not.

Re: Deprecating arithmetic on std::atomic<void*>

[Florian Weimer]

On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
> On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
>> On 20/04/17 08:19 +0200, Florian Weimer wrote:
>>> On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>>>> I know it's a bit late, but I'd like to propose deprecating the
>>>> libstdc++ extension that allows arithmetic on std::atomic<void*>.
>>>> Currently we make it behave like arithmetic on void*, which is also a
>>>> GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>>>> We also allow arithmetic on types such as std::atomic<void(*)()> which
>>>> is probably not useful (PR 69769).
>>>
>>> Why is it acceptable to have the extension for built-in types, but 
>>> not for library types wrapping them?  Why be inconsistent about this?
>>
>> C++17 [atomic.types.pointer] paragraph 4 says:
>>
>> 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]
>>
>> That doesn't give us any leeway to support it.

If we can ignore the Note, we can also ignore the requirement …

> I suppose we could support it without -Wpedantic, although there's no
> way for the library to know if the front-end is being pedantic or not.

Could you use SFINAE to detect whether the compiler supports arithmetic 
on void *?

Thanks,
Florian

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 11:24 +0200, Florian Weimer wrote:
>On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
>>On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
>>>On 20/04/17 08:19 +0200, Florian Weimer wrote:
>>>>On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>>>>>I know it's a bit late, but I'd like to propose deprecating the
>>>>>libstdc++ extension that allows arithmetic on std::atomic<void*>.
>>>>>Currently we make it behave like arithmetic on void*, which is also a
>>>>>GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>>>>>We also allow arithmetic on types such as std::atomic<void(*)()> which
>>>>>is probably not useful (PR 69769).
>>>>
>>>>Why is it acceptable to have the extension for built-in types, 
>>>>but not for library types wrapping them?  Why be inconsistent 
>>>>about this?
>>>
>>>C++17 [atomic.types.pointer] paragraph 4 says:
>>>
>>>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]
>>>
>>>That doesn't give us any leeway to support it.
>
>If we can ignore the Note, we can also ignore the requirement …
>
>>I suppose we could support it without -Wpedantic, although there's no
>>way for the library to know if the front-end is being pedantic or not.
>
>Could you use SFINAE to detect whether the compiler supports 
>arithmetic on void *?

Probably. We'd have to move the relevant member functions into a new
base class in order to make them conditionally disabled.

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 10:31 +0100, Jonathan Wakely wrote:
>On 20/04/17 11:24 +0200, Florian Weimer wrote:
>>On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
>>>On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
>>>>On 20/04/17 08:19 +0200, Florian Weimer wrote:
>>>>>On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>>>>>>I know it's a bit late, but I'd like to propose deprecating the
>>>>>>libstdc++ extension that allows arithmetic on std::atomic<void*>.
>>>>>>Currently we make it behave like arithmetic on void*, which is also a
>>>>>>GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>>>>>>We also allow arithmetic on types such as std::atomic<void(*)()> which
>>>>>>is probably not useful (PR 69769).
>>>>>
>>>>>Why is it acceptable to have the extension for built-in types, 
>>>>>but not for library types wrapping them?  Why be inconsistent 
>>>>>about this?
>>>>
>>>>C++17 [atomic.types.pointer] paragraph 4 says:
>>>>
>>>>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]
>>>>
>>>>That doesn't give us any leeway to support it.
>>
>>If we can ignore the Note, we can also ignore the requirement …
>>
>>>I suppose we could support it without -Wpedantic, although there's no
>>>way for the library to know if the front-end is being pedantic or not.
>>
>>Could you use SFINAE to detect whether the compiler supports 
>>arithmetic on void *?
>
>Probably. We'd have to move the relevant member functions into a new
>base class in order to make them conditionally disabled.

No, that doesn't work, because non-standard extensions are always
disabled in SFINAE contexts. It also wouldn't allow distinguishing
between -pedantic and -pedantic-errors.

Making the __atomic built-ins respect the pedantic flag is the right
way to handle it.

Or simply deprecate support for it in std::atomic. **If** the
extension for built-in types is useful then I can imagine it might be
useful to have it for std::atomic too, for a subset of the programs
relying on the original extension. But I'm unconvinced how useful
the original extension is. There are other ways to achieve it if
absolutely necessary, e.g. convert the void* to uintptr_t and perform
the arithmetic and use compare_exchange to store it back again.

Re: Deprecating arithmetic on std::atomic<void*>

[Florian Weimer]

On 04/20/2017 11:39 AM, Jonathan Wakely wrote:
> Or simply deprecate support for it in std::atomic. **If** the
> extension for built-in types is useful then I can imagine it might be
> useful to have it for std::atomic too, for a subset of the programs
> relying on the original extension. But I'm unconvinced how useful
> the original extension is. There are other ways to achieve it if
> absolutely necessary, e.g. convert the void* to uintptr_t and perform
> the arithmetic and use compare_exchange to store it back again.

GNU C programs routinely use pointer arithmetic on void *.  I see less 
need in C++ programs, simply because the use of void * is less common there.

Function pointer arithmetic is more tricky.  A side effect of it is that 
sizeof of a function type is defined as 1 (instead of a compiler error 
or the actual size, in bytes, of the function in question).  This had 
the unintended consequence that it took years to spot that a certain 
test for a non-executable stack was completely bogus (it always crashed 
because only one byte of the function was copied to the stack, and not 
the entire function).  I don't know of any application beyond that.

Thanks,
Florian

Re: Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 11:48 +0200, Florian Weimer wrote:
>On 04/20/2017 11:39 AM, Jonathan Wakely wrote:
>>Or simply deprecate support for it in std::atomic. **If** the
>>extension for built-in types is useful then I can imagine it might be
>>useful to have it for std::atomic too, for a subset of the programs
>>relying on the original extension. But I'm unconvinced how useful
>>the original extension is. There are other ways to achieve it if
>>absolutely necessary, e.g. convert the void* to uintptr_t and perform
>>the arithmetic and use compare_exchange to store it back again.
>
>GNU C programs routinely use pointer arithmetic on void *.  I see less 
>need in C++ programs, simply because the use of void * is less common 
>there.

And I see even less need to do it atomically.

>Function pointer arithmetic is more tricky.  A side effect of it is 
>that sizeof of a function type is defined as 1 (instead of a compiler 
>error or the actual size, in bytes, of the function in question).  
>This had the unintended consequence that it took years to spot that a 
>certain test for a non-executable stack was completely bogus (it 
>always crashed because only one byte of the function was copied to the 
>stack, and not the entire function).  I don't know of any application 
>beyond that.
>
>Thanks,
>Florian

Re: Deprecating arithmetic on std::atomic<void*>

[Pedro Alves]

On 04/20/2017 10:39 AM, Jonathan Wakely wrote:
> 
> Or simply deprecate support for it in std::atomic. **If** the
> extension for built-in types is useful then I can imagine it might be
> useful to have it for std::atomic too, for a subset of the programs
> relying on the original extension. But I'm unconvinced how useful
> the original extension is. There are other ways to achieve it if
> absolutely necessary, e.g. convert the void* to uintptr_t and perform
> the arithmetic and use compare_exchange to store it back again.

This comes from a completely different angle, but, 
if P0146R1 (Regular void) [1] manages to follow through, then that
makes GCC's extension for built-in types be standard, AFAICS.

AFAIK, the author is still pushing for the proposal aiming at C++20 [2].

[1] - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0146r1.html

[2] - <https://channel9.msdn.com/Shows/CppCast/Episode-83-Regular-Void-with-Matt-Calabrese>,
      end of last Feb, at min 14 onward.

( Please don't shoot the messenger. :-) )

Thanks,
Pedro Alves

Re: Deprecating arithmetic on std::atomic<void*>

[Marc Glisse]

On Thu, 20 Apr 2017, Florian Weimer wrote:

> On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>> I know it's a bit late, but I'd like to propose deprecating the
>> libstdc++ extension that allows arithmetic on std::atomic<void*>.
>> Currently we make it behave like arithmetic on void*, which is also a
>> GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>> We also allow arithmetic on types such as std::atomic<void(*)()> which
>> is probably not useful (PR 69769).
>
> Why is it acceptable to have the extension for built-in types, but not for 
> library types wrapping them?  Why be inconsistent about this?

I thought the extension was there for legacy code, to avoid breaking old 
programs, and we could deprecate it eventually. At least the manual is 
missing an example of where this extension is actually useful. For atomic, 
I don't see why we should encourage people to write new code that violates 
the standard...

-- 
Marc Glisse