* Deprecating arithmetic on std::atomic<void*> @ 2017-04-19 17:07 Jonathan Wakely 2017-04-19 17:43 ` Ville Voutilainen 2017-04-20 6:19 ` Florian Weimer 0 siblings, 2 replies; 24+ messages in thread From: Jonathan Wakely @ 2017-04-19 17:07 UTC (permalink / raw) To: gcc, libstdc++ 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<void*></code> + and types like <code>std::atomic<R(*)()></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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-19 17:07 Deprecating arithmetic on std::atomic<void*> Jonathan Wakely @ 2017-04-19 17:43 ` Ville Voutilainen 2017-04-20 6:19 ` Florian Weimer 1 sibling, 0 replies; 24+ messages in thread From: Ville Voutilainen @ 2017-04-19 17:43 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc, libstdc++ 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<void*></code> > + and types like <code>std::atomic<R(*)()></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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-19 17:07 Deprecating arithmetic on std::atomic<void*> Jonathan Wakely 2017-04-19 17:43 ` Ville Voutilainen @ 2017-04-20 6:19 ` Florian Weimer 2017-04-20 9:18 ` Jonathan Wakely 2017-04-20 9:31 ` Marc Glisse 1 sibling, 2 replies; 24+ messages in thread From: Florian Weimer @ 2017-04-20 6:19 UTC (permalink / raw) To: Jonathan Wakely, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 6:19 ` Florian Weimer @ 2017-04-20 9:18 ` Jonathan Wakely 2017-04-20 9:21 ` Jakub Jelinek 2017-04-20 9:22 ` Jonathan Wakely 2017-04-20 9:31 ` Marc Glisse 1 sibling, 2 replies; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:18 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc, libstdc++ 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 :-) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:18 ` Jonathan Wakely @ 2017-04-20 9:21 ` Jakub Jelinek 2017-04-20 9:25 ` Jonathan Wakely 2017-04-20 9:22 ` Jonathan Wakely 1 sibling, 1 reply; 24+ messages in thread From: Jakub Jelinek @ 2017-04-20 9:21 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Florian Weimer, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:21 ` Jakub Jelinek @ 2017-04-20 9:25 ` Jonathan Wakely 2017-04-20 9:30 ` Jakub Jelinek ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:25 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Florian Weimer, gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:25 ` Jonathan Wakely @ 2017-04-20 9:30 ` Jakub Jelinek 2017-04-20 9:30 ` Jonathan Wakely 2017-04-20 9:43 ` Florian Weimer 2 siblings, 0 replies; 24+ messages in thread From: Jakub Jelinek @ 2017-04-20 9:30 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Florian Weimer, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:25 ` Jonathan Wakely 2017-04-20 9:30 ` Jakub Jelinek @ 2017-04-20 9:30 ` Jonathan Wakely 2017-04-20 9:43 ` Florian Weimer 2 siblings, 0 replies; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:30 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Florian Weimer, gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:25 ` Jonathan Wakely 2017-04-20 9:30 ` Jakub Jelinek 2017-04-20 9:30 ` Jonathan Wakely @ 2017-04-20 9:43 ` Florian Weimer 2017-04-20 9:52 ` Jonathan Wakely 2 siblings, 1 reply; 24+ messages in thread From: Florian Weimer @ 2017-04-20 9:43 UTC (permalink / raw) To: Jonathan Wakely, Jakub Jelinek; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:43 ` Florian Weimer @ 2017-04-20 9:52 ` Jonathan Wakely 2017-04-20 9:57 ` Florian Weimer 0 siblings, 1 reply; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:52 UTC (permalink / raw) To: Florian Weimer; +Cc: Jakub Jelinek, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:52 ` Jonathan Wakely @ 2017-04-20 9:57 ` Florian Weimer 2017-04-20 10:03 ` Jonathan Wakely 0 siblings, 1 reply; 24+ messages in thread From: Florian Weimer @ 2017-04-20 9:57 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Jakub Jelinek, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:57 ` Florian Weimer @ 2017-04-20 10:03 ` Jonathan Wakely 2017-04-20 10:07 ` Jakub Jelinek 0 siblings, 1 reply; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 10:03 UTC (permalink / raw) To: Florian Weimer; +Cc: Jakub Jelinek, gcc, libstdc++ 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". ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 10:03 ` Jonathan Wakely @ 2017-04-20 10:07 ` Jakub Jelinek 2017-04-20 10:12 ` Jonathan Wakely 0 siblings, 1 reply; 24+ messages in thread From: Jakub Jelinek @ 2017-04-20 10:07 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Florian Weimer, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 10:07 ` Jakub Jelinek @ 2017-04-20 10:12 ` Jonathan Wakely 2017-04-20 11:20 ` Jonathan Wakely 0 siblings, 1 reply; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 10:12 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Florian Weimer, gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 10:12 ` Jonathan Wakely @ 2017-04-20 11:20 ` Jonathan Wakely 2017-04-20 12:20 ` Jonathan Wakely 0 siblings, 1 reply; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 11:20 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Florian Weimer, gcc, libstdc++ 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 === ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 11:20 ` Jonathan Wakely @ 2017-04-20 12:20 ` Jonathan Wakely 0 siblings, 0 replies; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 12:20 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Florian Weimer, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:18 ` Jonathan Wakely 2017-04-20 9:21 ` Jakub Jelinek @ 2017-04-20 9:22 ` Jonathan Wakely 2017-04-20 9:25 ` Florian Weimer 1 sibling, 1 reply; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:22 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:22 ` Jonathan Wakely @ 2017-04-20 9:25 ` Florian Weimer 2017-04-20 9:31 ` Jonathan Wakely 0 siblings, 1 reply; 24+ messages in thread From: Florian Weimer @ 2017-04-20 9:25 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:25 ` Florian Weimer @ 2017-04-20 9:31 ` Jonathan Wakely 2017-04-20 9:39 ` Jonathan Wakely 0 siblings, 1 reply; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:31 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:31 ` Jonathan Wakely @ 2017-04-20 9:39 ` Jonathan Wakely 2017-04-20 9:49 ` Florian Weimer 2017-04-20 11:29 ` Pedro Alves 0 siblings, 2 replies; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:39 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:39 ` Jonathan Wakely @ 2017-04-20 9:49 ` Florian Weimer 2017-04-20 9:53 ` Jonathan Wakely 2017-04-20 11:29 ` Pedro Alves 1 sibling, 1 reply; 24+ messages in thread From: Florian Weimer @ 2017-04-20 9:49 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:49 ` Florian Weimer @ 2017-04-20 9:53 ` Jonathan Wakely 0 siblings, 0 replies; 24+ messages in thread From: Jonathan Wakely @ 2017-04-20 9:53 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 9:39 ` Jonathan Wakely 2017-04-20 9:49 ` Florian Weimer @ 2017-04-20 11:29 ` Pedro Alves 1 sibling, 0 replies; 24+ messages in thread From: Pedro Alves @ 2017-04-20 11:29 UTC (permalink / raw) To: Jonathan Wakely, Florian Weimer; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Deprecating arithmetic on std::atomic<void*> 2017-04-20 6:19 ` Florian Weimer 2017-04-20 9:18 ` Jonathan Wakely @ 2017-04-20 9:31 ` Marc Glisse 1 sibling, 0 replies; 24+ messages in thread From: Marc Glisse @ 2017-04-20 9:31 UTC (permalink / raw) To: Florian Weimer; +Cc: Jonathan Wakely, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-04-20 12:20 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-19 17:07 Deprecating arithmetic on std::atomic<void*> Jonathan Wakely 2017-04-19 17:43 ` Ville Voutilainen 2017-04-20 6:19 ` Florian Weimer 2017-04-20 9:18 ` Jonathan Wakely 2017-04-20 9:21 ` Jakub Jelinek 2017-04-20 9:25 ` Jonathan Wakely 2017-04-20 9:30 ` Jakub Jelinek 2017-04-20 9:30 ` Jonathan Wakely 2017-04-20 9:43 ` Florian Weimer 2017-04-20 9:52 ` Jonathan Wakely 2017-04-20 9:57 ` Florian Weimer 2017-04-20 10:03 ` Jonathan Wakely 2017-04-20 10:07 ` Jakub Jelinek 2017-04-20 10:12 ` Jonathan Wakely 2017-04-20 11:20 ` Jonathan Wakely 2017-04-20 12:20 ` Jonathan Wakely 2017-04-20 9:22 ` Jonathan Wakely 2017-04-20 9:25 ` Florian Weimer 2017-04-20 9:31 ` Jonathan Wakely 2017-04-20 9:39 ` Jonathan Wakely 2017-04-20 9:49 ` Florian Weimer 2017-04-20 9:53 ` Jonathan Wakely 2017-04-20 11:29 ` Pedro Alves 2017-04-20 9:31 ` Marc Glisse
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).