[PATCH] free MPFR caches in gimple-ssa-sprintf.c (PR 79699)

Andrew Pinski pinskia@gmail.com
Thu Mar 2 21:40:00 GMT 2017


On Thu, Mar 2, 2017 at 1:33 PM, Martin Sebor <msebor@gmail.com> wrote:
> On 03/02/2017 01:08 AM, Richard Biener wrote:
>>
>> On Thu, Mar 2, 2017 at 2:01 AM, Joseph Myers <joseph@codesourcery.com>
>> wrote:
>>>
>>> On Wed, 1 Mar 2017, Martin Sebor wrote:
>>>
>>>> Joseph, since you commented on the bug, do you have a suggestion
>>>> for a different site for it or a guard?  The only other call to
>>>> the function is in the Fortran FE and it's neither guarded nor
>>>> does it appear to ever be called.
>>>
>>>
>>> I don't think a guard is needed.  Arguably it should be called from an
>>> atexit handler, but since we don't have such a handler calling it from
>>> the
>>> relevant pass seems reasonable (and I'm not sure what the right way to
>>> handle such freeing of memory in the JIT context is).
>>
>>
>> IMHO we should call it from gcc::~context
>
>
> Thanks, that makes sense to me.  The attached patch does that.

Is this function call thread safe?  Or rather is MPFR thread safe?
I am thinking of the case where there are two gcc::context around one
running in each thread.  I am not saying this is the current behavior
but I do know there was talk about making GCC thread safe before and I
want to make sure we understand that this might cause issues in that
goal.

Thanks,
Andrew

>
> Martin



More information about the Gcc-patches mailing list