From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90539 invoked by alias); 25 Feb 2020 17:20:20 -0000 Mailing-List: contact libstdc++-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libstdc++-owner@gcc.gnu.org Received: (qmail 90524 invoked by uid 89); 25 Feb 2020 17:20:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*f:sk:CAFk2RU, H*i:sk:CAFk2RU, H*f:sk:XAnJeAS, H*i:sk:XAnJeAS X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Feb 2020 17:20:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582651216; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3SW/5vcTnye2GArxbw2zhbZ/BlBUMCDniFXbC1sCdJE=; b=apVqGsFBz0gEropZEQYSfh5OUn4+96gVTQJq8H0J6r5hWMw34/5vBBsRxnfZdx8hVNztlc 3BGkWUNB3TYUcRlCkPR0k1VXlHFUq9WScOh5xV33zdqMpy9AUtc/AqCP28zpr6FjgoeeE+ 2fsWuKr5r7hEZH+Z2ETdMeN5ytra/r8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-277-IcIt1rjPODOS7B-F4DUt4w-1; Tue, 25 Feb 2020 12:20:12 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 75FBC107ACC4; Tue, 25 Feb 2020 17:20:11 +0000 (UTC) Received: from localhost (unknown [10.33.36.96]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0C408271A6; Tue, 25 Feb 2020 17:20:10 +0000 (UTC) Date: Tue, 25 Feb 2020 17:20:00 -0000 From: Jonathan Wakely To: Ville Voutilainen Cc: libstdc++ , gcc-patches List Subject: Re: [committed] libstdc++: Fix regression in std::move algorithm (PR 93872) Message-ID: <20200225172010.GL9441@redhat.com> References: <20200225124056.GA2337630@redhat.com> <20200225133609.GK9441@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00178.txt.bz2 On 25/02/20 16:01 +0200, Ville Voutilainen wrote: >On Tue, 25 Feb 2020 at 15:36, Jonathan Wakely wrote: >> I think what I'd really like to do is get rid of __memmove entirely. >> We already have code that does the explicit assignment in a loop, for >> the cases where we can't use __builtin_memmove because the type is not >> trivially copyable. >> >> We should just use that existing code during constant evaluation, i.e. >> don't do the __builtin_memmove optimizations during constant >> evaluation. It seems much cleaner to just not use the optimization >> rather than wrap it to be usable in constant expressions. >> >> We already have to do that for {copy,move}_backward anyway, because >> __memmove doesn't correctly implement the std::memmove semantics for >> overlapping ranges. But we do it **wrong** and turn copy_backward into >> move_backward during constant evaluation. >> >> Here's a patch that gets rid of __memmove and fixes that bug >> (generated with 'git diff -b' so that the changes to the logic aren't >> obscured by the whitespace changes caused by re-indenting). >> >> Maybe I should just go ahead and do this now, since __memmove (and the >> problems it causes) are new for GCC 10 anyway. That would revert >> to something closer to the GCC 9 version. > >Looks good to me. I've committed it now. It's not strictly a regression, because the bug only happens when using std::copy_backwards in a constant expression, which never compiled before GCC 10 anyway. But enabling it to be used in constant expressions but with incorrect results doesn't seem useful.