This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] Runtime memory leak checking.

Dear Janus,

>> I just updated the memleak patch to current trunk, since I
>> incidentally found some use for it lately and wanted to try it.
>> Up to now I basically just re-diffed it (repairing some failed hunks)
>> and fixed some indentation problems reported by Mikael, but maybe I'll
>> be working some more on this soon. Seems like the patch may be almost
>> ready to go into trunk, I guess?

It is... up to the legal problem which was brought up when it was last
discussed.  I have to sya that I find this to be incredible but it
seems that there is a real question concerning the use of libiberty in

In fact, I wondered whether a hash table should be used at all.  A
binary search on the address of the memory would be more efficient and
would avoid any possibility of collisions.

I presume that 'bsearch' from stdlib would be OK in libgfortran???

As for the other issues, I have not looked into them because of the
resounding lack of interest in this patch.  Personally, I like it and
have reapplied it to do the memory leaks with allocatable components.
In fact, I rather think that the fix is going to involve
memory_check.c :-)  To this end, I have been looking for legal search
functions that are efficient and do not suffer from potential



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]