From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87297 invoked by alias); 2 Jan 2020 10:28:31 -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 87274 invoked by uid 89); 2 Jan 2020 10:28:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=unavailable version=3.3.1 spammy= X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 Jan 2020 10:28:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1577960908; 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=barKuI2gY81n0pRI3qmwMe9c/5Be/YksfgFx7SfxY5I=; b=Hz4XNPwfo/3jta4QvYSxrFYJx5la3MY6LnUkkUsKJnCti864bboUcUWCLyLgQLxNRxWka3 xUvGX9fV2nhUb8xml0DDh5Iu1Egy4PmBA75cnuhF8UlPeXOym4tOw4AQuRG9f5ulAcmvq1 uxVzltXq/m1GCyoCwHCQ7GNAvelBCaw= 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-108-JIlH--btNde6mHXSwetKXQ-1; Thu, 02 Jan 2020 05:28:25 -0500 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id C69DA107ACC7; Thu, 2 Jan 2020 10:28:23 +0000 (UTC) Received: from localhost (unknown [10.33.36.89]) by smtp.corp.redhat.com (Postfix) with ESMTP id 596DB5D9C9; Thu, 2 Jan 2020 10:28:23 +0000 (UTC) Date: Thu, 02 Jan 2020 10:28:00 -0000 From: Jonathan Wakely To: JeanHeyd Meneide Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org, libstdc++ Subject: Re: [ PATCH ] [ C++ ] [ libstdc++ ] P1208r6 Merge source_location Message-ID: <20200102102822.GL40198@redhat.com> References: <20191227193329.GM10088@tucnak> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00001.txt.bz2 On 27/12/19 22:27 -0500, JeanHeyd Meneide wrote: >On Fri, Dec 27, 2019 at 2:33 PM Jakub Jelinek wrote: >> >> This will be ABI incompatible between GCC and Clang, that doesn't look l= ike >> a good idea to me. I thought the plan is to use what you have in the >> _GLIBCXX_HAVE_BUILTIN_SOURCE_LOCATION case always, except that if >> __builtin_source_location isn't available, initialize _M_data to nullptr. > >You're right, it's probably bad to have an implementation that >switches. I guess that means clang folks will have to implement the >builtin too at some point (but Jonathan's comment in the >__builtin_source_location patch said they might not, so I'm not sure >what to do for Clang here I guess?). Do nothing - compiling with Clang won't define std::source_location at all.