From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12264 invoked by alias); 4 May 2016 16:19:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11366 invoked by uid 89); 4 May 2016 16:19:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=codecvt_utf8, andre, Andre X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 May 2016 16:19:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0D42B3A; Wed, 4 May 2016 09:19:17 -0700 (PDT) Received: from [10.2.206.221] (e107157-lin.cambridge.arm.com [10.2.206.221]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 052A33F215; Wed, 4 May 2016 09:19:09 -0700 (PDT) Subject: Re: [patch] libstdc++/69703 ignore endianness in codecvt_utf8 References: <20160419180305.GB3577@redhat.com> <20160419180629.GC3577@redhat.com> <20160419180749.GD3577@redhat.com> <20160420174028.GK3577@redhat.com> From: "Andre Vieira (lists)" Cc: gcc-patches@gcc.gnu.org To: jwakely@redhat.com Message-ID: <572A20FC.7080702@arm.com> Date: Wed, 04 May 2016 16:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20160420174028.GK3577@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00323.txt.bz2 On 20/04/16 18:40, Jonathan Wakely wrote: > On 19/04/16 19:07 +0100, Jonathan Wakely wrote: >> This was reported as a bug in the Filesystem library, but it's >> actually a problem in the codecvt_utf8 facet that it uses. > > The fix had a silly typo meaning it didn't work for big endian > targets, which was revealed by the improved tests I added. > > Tested x86_64-linux and powerpc64-linux, committed to trunk. > > Hi Jonathan, We are seeing experimental/filesystem/path/native/string.cc fail on baremetal targets. I'm guessing this is missing a 'dg-require-filesystem-ts', as seen on other tests like experimental/filesystem/path/modifiers/swap.cc. Cheers, Andre