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 <HOST_TYPE>. */
The specific code you refer to is here (approx line 4176 of
jit-recording.c):
/* The write_reproducer specialization for <long>. */
template <>
void
recording::memento_of_new_rvalue_from_const <long>::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
