egcs-971023: Purify warning 'Uninitialized memory read'

[Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>]

Hello!

The following simple code example leads to 'Uninitialized memory read'
messages from purify:

----------------- code -------------------
#include <vector>

const unsigned int c = 1;

int main()
{
    vector<int> v(c, 0);
}
--------------- end code -----------------

compiled with g++ -g -Wall -c
linked with purify



The error occurs at algobase.h:664:
   template <class ForwardIterator, class Size, class T>
   inline ForwardIterator
   __uninitialized_fill_n_aux(ForwardIterator first, Size n,
=>                            const T& x, __true_type) {
     return fill_n(first, n, x);
   }



Here's the complete purify stacktrace (sorry for the long lines):
      UMR: Uninitialized memory read
      This is occurring while in:
            __uninitialized_fill_n_aux__H3ZPiZUiZi_X01X11RCX21G11__true_type_X01 [algobase.h:664]
               template <class ForwardIterator, class Size, class T>
               inline ForwardIterator
               __uninitialized_fill_n_aux(ForwardIterator first, Size n,
            =>                            const T& x, __true_type) {
                 return fill_n(first, n, x);
               }
               
            __uninitialized_fill_n__H4ZPiZUiZiZi_X01X11RCX21PX31_X01 [algobase.h:692]
               inline ForwardIterator __uninitialized_fill_n(ForwardIterator first, Size n,
                                                             const T& x, T1*) {
                 return __uninitialized_fill_n_aux(first, n, x,
            =>                                     __type_traits<T1>::is_POD_type());
               }
               
               template <class ForwardIterator, class Size, class T>
            uninitialized_fill_n__H3ZPiZUiZi_X01X11RCX21_X01 [algobase.h:698]
               template <class ForwardIterator, class Size, class T>
               inline ForwardIterator uninitialized_fill_n(ForwardIterator first, Size n,
                                                           const T& x) {
            =>   return __uninitialized_fill_n(first, n, x, value_type(first));
               }
               
               // Copies [first1, last1) into [result, result + (last1 - first1)), and
            allocate_and_fill__t6vector2ZiZt24__default_alloc_template2b0i0UiRCi [vector.h:206]
               #         ifdef __STL_USE_EXCEPTIONS
                     try {
               #         endif /* __STL_USE_EXCEPTIONS */
            =>         uninitialized_fill_n(result, n, x);
                       return result;
               #         ifdef __STL_USE_EXCEPTIONS
                     }
            fill_initialize__t6vector2ZiZt24__default_alloc_template2b0i0UiRCi [vector.h:66]
                   }
               
                   void fill_initialize(size_type n, const T& value) {
            =>       start = allocate_and_fill(n, value);
                     finish = start + n;
                     end_of_storage = finish;
                   }
            __t6vector2ZiZt24__default_alloc_template2b0i0UiRCi [vector.h:91]
                   const_reference operator[](size_type n) const { return *(begin() + n); }
               
                   vector() : start(0), finish(0), end_of_storage(0) {}
            =>     vector(size_type n, const T& value) { fill_initialize(n, value); }
                   vector(int n, const T& value) { fill_initialize(n, value); }
                   vector(long n, const T& value) { fill_initialize(n, value); }
                   explicit vector(size_type n) { fill_initialize(n, T()); }
      Reading 1 byte from 0xeffff0ff on the stack.
      Address 0xeffff0ff is 17 bytes below frame pointer in function __uninitialized_fill_n__H4ZPiZUiZiZi_X01X11RCX21PX31_X01.


Since all parameters 'ForwardIterator first', 'Size n' and 'const T& x'
seem to be initialized allright, it might be that the dummy-parameter
of type __true_type is the reason ? 

__true_type is defined in type_traits.h as follows:

struct __true_type {
};

No elements, no constructor. Therefore no initialized members, but still
some memory usage! Maybe at algobase.h:664 the compiler generates some
unnecessary access to the unnamed parameter ?


At destruction there's a similar warning:
      UMR: Uninitialized memory read
      This is occurring while in:
            __destroy_aux__H1ZPi_X01T0G11__true_type_v [algobase.h:506]
               }
               
               template <class ForwardIterator> 
            => inline void __destroy_aux(ForwardIterator, ForwardIterator, __true_type) {
               }
               
               template <class ForwardIterator, class T>
            __destroy__H2ZPiZi_X01T0PX11_v [algobase.h:511]
               
               template <class ForwardIterator, class T>
               inline void __destroy(ForwardIterator first, ForwardIterator last, T*) {
            =>   __destroy_aux(first, last, __type_traits<T>::has_trivial_destructor());
               }
               
               template <class ForwardIterator>
            destroy__H1ZPi_X01T0_v [algobase.h:516]
               
               template <class ForwardIterator>
               inline void destroy(ForwardIterator first, ForwardIterator last) {
            =>   __destroy(first, last, value_type(first));
               }
               
               inline void destroy(char*, char*) {}
            _._t6vector2ZiZt24__default_alloc_template2b0i0 [vector.h:117]
                   }
               #endif /* __STL_MEMBER_TEMPLATES */
                   ~vector() { 
            =>         destroy(start, finish);
                       deallocate();
                   }
                   vector<T, Alloc>& operator=(const vector<T, Alloc>& x);
            main           [test.cc:5]
               
               int main()
               {
            =>     vector<int> v((unsigned int)1, 0);
               }
            _start         [crt1.o]
      Reading 1 byte from 0xeffff1e7 on the stack.
      Address 0xeffff1e7 is 17 bytes below frame pointer in function __destroy__H2ZPiZi_X01T0PX11_v.



Hope this is helpful, if not, mail me.


Best regards, Dirk Herrmann