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
