purify experiments

[Joe Buck <jbuck at synopsys dot com>]

Hi,

(all experiments are with sparc-sun-solaris2.5.1)

I just did a purify test on a subset of the previous example tdeque.cxx;
the only change is that I reduced the main program to just

int main() {
    deque_test(make_pair(1,2), make_pair(2,3), make_pair(3,5));
}

so the number of templates built gets divided by three (this case grows
to 113M instead of 492M with the bootstrapped egcs).  Because Purify
seems to have problems with 2.8.0/egcs object code, and because I wanted
to see easy-to-understand stack traces, I built a new cc1plus using
gcc 2.7.2.1 with the -g option.  I verified that it has the same problem
(that cc1plus -O tdeque.ii gets huge).

First, uninitialized memory reads (UMR's).  There's a probably-harmless
UMR caused by doing qsort on structs that don't have all fields set.
There's a more worrying one, though, in unify (file pt.c, line 3191):


           case TEMPLATE_TYPE_PARM:
    =>       (*nsubsts)++;
             idx = TEMPLATE_TYPE_IDX (parm);
             if (strict && (TYPE_READONLY (arg) < TYPE_READONLY (parm)
                            || TYPE_VOLATILE (arg) < TYPE_VOLATILE (parm)))

Otherwise no UMR's.

I was afraid that I wouldn't see leaks because of gcc's habit of doing
allocation through obstacks: an obstack could have a huge amount of junk
that would disappear at the end of the program.  However, there are
significant leaks, though not enough to explain the whole problem.

Over 6 megabytes are leaked, and 15 additional megabytes are "potentially
leaked" (meaning that there is something that looks like a pointer into
the middle of the object but not the beginning) from one source: memory
allocated at line 1810 of find_exception_handler_labels:

        /* We call xmalloc here instead of alloca; we did the latter in the past,
           but found that it can sometimes end up being asked to allocate space
           for more than 1 million labels.  */
   =>   labels = (rtx *) xmalloc ((max_labelno - min_labelno) * sizeof (rtx));
        bzero ((char *) labels, (max_labelno - min_labelno) * sizeof (rtx));
      
        /* Arrange for labels to be indexed directly by CODE_LABEL_NUMBER.  */

However, I've verified that exceptions are not the main problem.  If
I go back to the original example (using the bootstrapped egcs gcc this
time),

gcc -c -O -fno-exceptions tdeque.cxx

needs 395M, while

gcc -c -O tdeque.cxx

needs 492M.

So it seems that the problem must be related to too much being saved in
obstacks.  Are all the generated template functions being saved, as for inline
functions?