On Mon, 2020-08-03 at 10:07 +0200, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
> >
> > [...]
> >
> >> I haven't thought this through in detail, and I'm not sure exactly
> >> how
> >> it would work for arbitrary types,
David Malcolm writes:
> On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
>
> [...]
>
>> I haven't thought this through in detail, and I'm not sure exactly
>> how
>> it would work for arbitrary types, but I thought it worth sharing.
>> (For example I can think of nasty issu
On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote:
[...]
> I haven't thought this through in detail, and I'm not sure exactly
> how
> it would work for arbitrary types, but I thought it worth sharing.
> (For example I can think of nasty issues if we ever want to support
> cr
On Wed, 2020-07-01 at 18:14 +0200, Andrea Corallo wrote:
> Andrea Corallo writes:
>
> > > It occurred to me that the entrypoint is combining two things:
> > > - creating a global char[]
> > > - creating an initializer for that global
> > >
> > > which got me wondering if we should instead have a
Andrea Corallo writes:
> Andrea Corallo writes:
>
>>> It occurred to me that the entrypoint is combining two things:
>>> - creating a global char[]
>>> - creating an initializer for that global
>>>
>>> which got me wondering if we should instead have a way to add
>>> initializers for globals.
>>
Andrea Corallo writes:
>> It occurred to me that the entrypoint is combining two things:
>> - creating a global char[]
>> - creating an initializer for that global
>>
>> which got me wondering if we should instead have a way to add
>> initializers for globals.
>>
>> My first thought was something
David Malcolm writes:
> Thanks for the patch.
>
> Is this entrypoint only needed for the ahead-of-time use case? If the
> client code is instead going to do an in-memory compilation, then I
> believe it can simply build the buffer of data in memory and expose it
> to the jitted code via gcc_jit_
On Wed, 2020-06-03 at 12:11 +0200, Andrea Corallo wrote:
> Hi all,
>
> I'd like to submit this patch to extend libgccjit to allow for
> storing
> binary blobs (equivalent to initialized char arrays).
>
> The use-case is when libgccjit is used as a back-end for dynamic
> programming languages. In
Hi all,
I'd like to submit this patch to extend libgccjit to allow for storing
binary blobs (equivalent to initialized char arrays).
The use-case is when libgccjit is used as a back-end for dynamic
programming languages. In this case is often necessary to store
serialized objects into the compil
