From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25678 invoked by alias); 15 Nov 2019 12:49:15 -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 25668 invoked by uid 89); 15 Nov 2019 12:49:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham 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) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Nov 2019 12:49:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573822152; h=from:from:reply-to: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=ZmUl7cW8/jIXPzv+qokV6osl/zdZxjjXScbJSS7eLbc=; b=gTbQAt9s7q9/B1Ka7GrrOgOwnS4mmfDm7Nxb9KEYpv4GlTHY20zGyF1ZitBne0OTZZXTHe cOLLnO3CpcC8X20kvVsJRx3s9n2CLXENJVY86wG5C9Drvyz0y4V9/zJH5iLdZb4JHt50Ng MtU/PylHKkdzzrcaUQLcWbpn8bUw1PU= 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-189-ndQ1RLFjMeeozBqFcjvT6g-1; Fri, 15 Nov 2019 07:49:11 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 19C01802686 for ; Fri, 15 Nov 2019 12:49:10 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A6FAF5F78C; Fri, 15 Nov 2019 12:49:06 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id xAFCn53V011495; Fri, 15 Nov 2019 13:49:05 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id xAFCn4R9011494; Fri, 15 Nov 2019 13:49:04 +0100 Date: Fri, 15 Nov 2019 12:55:00 -0000 From: Jakub Jelinek To: Jonathan Wakely Cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] __builtin_source_location () Message-ID: <20191115124904.GL4650@tucnak> Reply-To: Jakub Jelinek References: <20191114193426.GE4650@tucnak> <20191115122817.GJ4650@tucnak> <20191115123522.GN17072@redhat.com> MIME-Version: 1.0 In-Reply-To: <20191115123522.GN17072@redhat.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg01390.txt.bz2 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 __c= olumn > > > fields, the first two with const char * type, the latter some integra= l type. > >=20 > > Here is hopefully final version, with the hashing implemented, > > __file renamed to __file_name and __function to __function_name to match > > how the standard names the methods and with testsuite coverage. >=20 > The libstdc++ naming convention says the data members should be > _M_file_name, _M_line etc. >=20 > 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? 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. Jakub