From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87282 invoked by alias); 20 Apr 2017 09:53:32 -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 87256 invoked by uid 89); 20 Apr 2017 09:53:31 -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:2864174, H*i:sk:2864174, H*MI:sk:2864174 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:53:30 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B31EEC04BD3C; Thu, 20 Apr 2017 09:53:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B31EEC04BD3C Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jwakely@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B31EEC04BD3C Received: from localhost (unknown [10.33.36.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6318B7F6BC; Thu, 20 Apr 2017 09:53:30 +0000 (UTC) Date: Thu, 20 Apr 2017 09:53: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: <20170420095328.GH3412@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> <20170420093102.GE3412@redhat.com> <20170420093956.GF3412@redhat.com> <28641743-de0f-01a6-409b-f321397b66b9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <28641743-de0f-01a6-409b-f321397b66b9@redhat.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.8.0 (2017-02-23) X-SW-Source: 2017-04/txt/msg00078.txt.bz2 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