From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87363 invoked by alias); 20 Apr 2017 09:31:05 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 87308 invoked by uid 89); 20 Apr 2017 09:31:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:520db01, H*i:sk:520db01, late X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Apr 2017 09:31:03 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 821C361D09; Thu, 20 Apr 2017 09:31:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 821C361D09 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jwakely@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 821C361D09 Received: from localhost (unknown [10.33.36.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2FD975B80D; Thu, 20 Apr 2017 09:31:03 +0000 (UTC) Date: Thu, 20 Apr 2017 09:31:00 -0000 From: Jonathan Wakely To: Florian Weimer Cc: gcc@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: Deprecating arithmetic on std::atomic Message-ID: <20170420093102.GE3412@redhat.com> References: <20170419170736.GY3412@redhat.com> <170e0b73-e561-82a9-7f26-e7b5d40a0f1c@redhat.com> <20170420091809.GA3412@redhat.com> <20170420092214.GB3412@redhat.com> <520db01e-9e9c-333f-2537-e8be4fcd7d1e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <520db01e-9e9c-333f-2537-e8be4fcd7d1e@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.8.0 (2017-02-23) X-SW-Source: 2017-04/txt/msg00072.txt.bz2 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. >>>>>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 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.