Hi,
On Thursday, May 22, 2014 03:38:12 Jose Fonseca wrote:
> In short, besides the existing gallivm_context (which is actually not per
> context, but rather per module/ compilation unit) there should be a new
> object, that's truly per context, that holds two things:
>
> - LLVMContextRef
> -
Hi,
On Thursday, May 22, 2014 03:38:12 Jose Fonseca wrote:
> Sorry for the delay.
Mostly the same here.
So don't worry!
I just want this to work somehow and I think the problem is already too long
standing ...
And the longer I think about that the longer I believe that we have already
discussed
Hi Mathias,
Sorry for the delay.
- Original Message -
>
> Hi Jose,
>
> I tried to get my local llvm install again to a point where I can see
> backtrace information, but still failed to get valgrind/massif to print
> these nice backtraces. All of the llvm addresses are not resolved so f
Hi,
On Monday, May 19, 2014 15:59:30 Michel Dänzer wrote:
> On 19.05.2014 15:03, Mathias Fröhlich wrote:
> >
> > I tried to get my local llvm install again to a point where I can see
> > backtrace information, but still failed to get valgrind/massif to print
> > these nice backtraces. All of the
On 19.05.2014 15:03, Mathias Fröhlich wrote:
>
> I tried to get my local llvm install again to a point where I can see
> backtrace information, but still failed to get valgrind/massif to print
> these nice backtraces. All of the llvm addresses are not resolved so far.
You may want to try some or
Hi Jose,
I tried to get my local llvm install again to a point where I can see
backtrace information, but still failed to get valgrind/massif to print
these nice backtraces. All of the llvm addresses are not resolved so far.
But a appart from that which gl example/test program do you run to see
Hi,
On Wednesday, May 14, 2014 02:45:26 Jose Fonseca wrote:
> If you rebase it on top of my series it can be reduced to merely this:
Ok, thanks that is actually great news, as this gives me something to work with.
> In other words, we'd be introducing leaks for sake of thread-safety. I care
>
- Original Message -
> On 05/14/2014 03:45 AM, Jose Fonseca wrote:
> > - Original Message -
> >>
> >> Hi Jose,
> >>
> >> On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote:
> >>> I tweaked the comment (was below) but indeed did a poor job. I think
> >>> I'll
> >>> just put the
On 05/14/2014 03:45 AM, Jose Fonseca wrote:
- Original Message -
Hi Jose,
On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote:
I tweaked the comment (was below) but indeed did a poor job. I think I'll
just put the original back:
"We must never free LLVM contexts, because LLVM h
- Original Message -
>
> Hi Jose,
>
> On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote:
> > I tweaked the comment (was below) but indeed did a poor job. I think I'll
> > just put the original back:
> >
> >"We must never free LLVM contexts, because LLVM has several global
> >
Hi Jose,
On Tuesday, May 13, 2014 08:16:34 Jose Fonseca wrote:
> I tweaked the comment (was below) but indeed did a poor job. I think I'll
> just put the original back:
>
>"We must never free LLVM contexts, because LLVM has several global caches
>which pointing/derived from objects own
- Original Message -
> On 05/13/2014 06:01 AM, jfons...@vmware.com wrote:
> > From: José Fonseca
> >
> > I saw that LLVM internally uses its global context for some things, even
> > when we use our own. Given ours is also global, might as well use
> > LLVM's.
> >
> > However, sepearate
On 05/13/2014 06:01 AM, jfons...@vmware.com wrote:
From: José Fonseca
I saw that LLVM internally uses its global context for some things, even
when we use our own. Given ours is also global, might as well use
LLVM's.
However, sepearate contexts can still be enabled with a simple source
code m
From: José Fonseca
I saw that LLVM internally uses its global context for some things, even
when we use our own. Given ours is also global, might as well use
LLVM's.
However, sepearate contexts can still be enabled with a simple source
code modification, for when the need/benefit arises.
---
s
14 matches
Mail list logo
