From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4370 invoked by alias); 15 Jul 2015 19:37:24 -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 4272 invoked by uid 89); 15 Jul 2015 19:37:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: ovh.starynkevitch.net Received: from ovh.starynkevitch.net (HELO ovh.starynkevitch.net) (46.105.17.220) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 15 Jul 2015 19:37:21 +0000 Received: from lstlambert-656-1-266-187.w193-248.abo.wanadoo.fr ([193.248.54.187] helo=[192.168.1.5]) by ovh.starynkevitch.net with esmtp (Exim 4.82) (envelope-from ) id 1ZFSUY-0008BT-35; Wed, 15 Jul 2015 21:37:18 +0200 Message-ID: <55A6B669.10104@starynkevitch.net> Date: Wed, 15 Jul 2015 19:56:00 -0000 From: Basile Starynkevitch User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: David Malcolm CC: gcc-patches@gcc.gnu.org, jit@gcc.gnu.org Subject: Re: PATCH trunk GCCJIT: adding gcc_jit_context_new_rvalue_from_long_long, etc... References: <55A6A421.8060707@starynkevitch.net> <1436986339.830.59.camel@surprise> In-Reply-To: <1436986339.830.59.camel@surprise> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg01331.txt.bz2 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! 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 :-) Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***