From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28937 invoked by alias); 15 Jul 2015 19:56:38 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 28916 invoked by uid 89); 15 Jul 2015 19:56:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Message-ID: <1436989719.830.66.camel@surprise> Subject: Re: PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc... From: David Malcolm To: Basile Starynkevitch Cc: gcc-patches@gcc.gnu.org, jit@gcc.gnu.org Date: Thu, 01 Jan 2015 00:00:00 -0000 In-Reply-To: <55A6B669.10104@starynkevitch.net> References: <55A6A421.8060707@starynkevitch.net> <1436986339.830.59.camel@surprise> <55A6B669.10104@starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-SW-Source: 2015-q3/txt/msg00095.txt.bz2 On Wed, 2015-07-15 at 21:37 +0200, Basile Starynkevitch wrote: > On 07/15/2015 20:52, David Malcolm wrote: > > On Wed, 2015-07-15 at 20:19 +0200, Basile Starynkevitch wrote: > >> Hello All and David Malcolm > >> > >> The attached patch (relative to trunk r224842) is adding > >> gcc_jit_context_new_rvalue_from_long_long and similar functions to > >> GCCJIT. > > > * dump_to_reproducer support (most testcases attempt to dump their > > contexts to a .c file and then sanity-check the generated c by > > compiling them, though not running them; see jit.exp). A new API > > entrypoint needs to "know" how to write itself back out to C (by > > implementing gcc::jit::recording::memento::write_reproducer for the > > appropriate memento subclass). > > > I'm sorry, but I can't understand the above comment. Where is the > "Implementation of recording::memento::write_reproducer for longs." I > can't find such comment in jit-recording.c! See approx line 4069 of jit-recording.c onwards: /* The implementation of the various const-handling classes: gcc::jit::recording::memento_of_new_rvalue_from_const . */ The specific code you refer to is here (approx line 4176 of jit-recording.c): /* The write_reproducer specialization for . */ template <> void recording::memento_of_new_rvalue_from_const ::write_reproducer (reproducer &r) { /* etc */ > BTW, it is really a pity that even a brand new subtree like gcc/jit/, > coded mostly in C++, uses *.c > as the file extension for newly introduced C++ files. There is no legacy > reason to use *.c extensions for new C++ files (as we had for source > files of twenty years of age). I really find that confusing. And no > comment mention that it is C++ not C! > It makes me almost cry :-) Sorry. I went with *.c for consistency with the rest of the source tree (and it's somewhat easier to grep that way). I agree that this is confusing, and merits at least a mention in docs/internals/index.rst. Dave