Re: Linking libgfortran with libiberty

[Paolo Bonzini <bonzini at gnu dot org>]

FX wrote:
>> +1.  If libgfortran includes a custom allocator of any sort (does it?)
>> instead of using malloc/free, it should use valgrind hooks like those we
>> already have in GCC.
> 
> libgfortran uses malloc/free.
> 
> Regarding valgrind, it's not supported on all GCC targets, so it's not a
> valid alternative to our proposal.

Each platform does have a valid alternative, IMO.  For example, I just
found http://xtalk.msk.su/~ott/en/writings/prog-checking/GooglePT.html
searching for "memory leak darwin tool".  Apple also has
platform-specific leak detection tools
(http://developer.apple.com/documentation/Performance/Conceptual/ManagingMemory/Articles/FindingLeaks.html).

For Windows, I found
http://www.codeproject.com/KB/applications/visualleakdetector.aspx which
is free (LGPL); I don't know how good it is and it may be hard to
compile it to GCC, but doing that would be a better service than adding
a leak detector to libgfortran (Purify is proprietary and expensive).

So yes, there are alternatives.  Anyway, as you said it's the gfortran
maintainers' choice.

> I can understand that you have
> objections based on licence issues to make to that patch, but I'm sure
> the gfortran maintainers are the best people to make the decision of
> whether this patch is a good thing for the project (and much demanded by
> the community);

... but the build patch you posted (or the concept below it), no, that
one I explicitly rejected as a build maintainer.  I was reluctant to do
that, but other developers voiced the same concerns I had and pinpointed
them more precisely than I could have done.  (Besides, a correct patch
would have included a libgfortran->libiberty dependency in the toplevel
Makefile.def).

Paolo