From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119293 invoked by alias); 15 Nov 2019 14:05:10 -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 119285 invoked by uid 89); 15 Nov 2019 14:05:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,KAM_SHORT autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.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; Fri, 15 Nov 2019 14:05:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573826707; 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=YEN1zV+7YcaRf9Y7wUV50Se1BoA9mRsFn+ymIm/tOH8=; b=VNJkH3uOwc1GVUKxJSZNW4MNk6y5dK9A/D/2eglW6YO2zL0+wXcess+hhKSUBINTdzl7uL CxHVIcH7m1GCZv3fTjZM1IXUba7vW7zwN9hRqismIMlSjb9Eof2hC+G98oKiZQeAkOQQlu rUhJvc5phgSXhpnHZu+7JI++kycE8ns= 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-113-wS3wR-YmPJeGiCYuyjaRqQ-1; Fri, 15 Nov 2019 09:05:05 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5F7971802CE1; Fri, 15 Nov 2019 14:05:04 +0000 (UTC) Received: from localhost (unknown [10.33.36.113]) by smtp.corp.redhat.com (Postfix) with ESMTP id 73AF5196BC; Fri, 15 Nov 2019 14:05:02 +0000 (UTC) Date: Fri, 15 Nov 2019 14:06:00 -0000 From: Jonathan Wakely To: Jakub Jelinek Cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] __builtin_source_location () Message-ID: <20191115140502.GO17072@redhat.com> References: <20191114193426.GE4650@tucnak> <20191115122817.GJ4650@tucnak> <20191115123522.GN17072@redhat.com> <20191115124904.GL4650@tucnak> MIME-Version: 1.0 In-Reply-To: <20191115124904.GL4650@tucnak> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.12.1 (2019-06-15) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2019-11/txt/msg01406.txt.bz2 On 15/11/19 13:49 +0100, Jakub Jelinek wrote: >On Fri, Nov 15, 2019 at 12:35:22PM +0000, Jonathan Wakely wrote: >> On 15/11/19 13:28 +0100, Jakub Jelinek wrote: >> > On Thu, Nov 14, 2019 at 08:34:26PM +0100, Jakub Jelinek wrote: >> > > The following WIP patch implements __builtin_source_location (), >> > > which returns const void pointer to a std::source_location::__impl >> > > struct that is required to contain __file, __function, __line and __= column >> > > fields, the first two with const char * type, the latter some integr= al type. >> > >> > Here is hopefully final version, with the hashing implemented, >> > __file renamed to __file_name and __function to __function_name to mat= ch >> > how the standard names the methods and with testsuite coverage. >> >> The libstdc++ naming convention says the data members should be >> _M_file_name, _M_line etc. >> >> Since this is just a normal library type now, not defined by the >> compiler, I think we should follow the library convention (sorry for >> not noticing that sooner). > >I guess it depends on what are the chances other compilers will implement >the same builtin, because doesn't say libc++ use __name rather than >_M_name convention? Yes, that's what libc++ uses, but I get the impression Clang isn't going to add this built-in anyway. >Yet another option would be for the builtin to accept either >_M_file_name or __file_name, could be handled by > const char *n =3D IDENTIFIER_POINTER (DECL_NAME (field)); > if (strncmp (n, "_M_", 3) =3D=3D 0) > n +=3D 3; > else if (strncmp (n, "__", 2) =3D=3D 0) > n +=3D 2; > else > n =3D ""; >and then do the comparisons without __ in the patch. My inclination is YAGNI. At this point, a libc++ implementation that would want to use __builtin_source_location when compiled with GCC is hypothetical, and would already need various #if conditions around it. BCCing libc++ maintainers in case they want to request that GCC's built-in pre-emptively support a std::source_location::__impl type that uses __ prefixes on its data members. For more context see https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01389.html and the rest of the thread.