[Bug c++/19343] New warnings in libstdc++-v3 since 2004-01-05

["aj at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From aj at gcc dot gnu dot org  2005-01-09 07:19 -------
Gaby comments in http://gcc.gnu.org/ml/libstdc++/2005-01/msg00064.html: 
 
This is a compiler regression.  The body of the function is: 
 
     _M_get(size_t __sz) throw(std::bad_alloc) 
     { 
   #if defined __GTHREADS 
       _Lock __bfl_lock(&_S_bfl_mutex); 
       __bfl_lock._M_lock(); 
   #endif 
       iterator __temp = 
         __gnu_cxx::balloc::__lower_bound 
         (_S_free_list.begin(), _S_free_list.end(), 
          __sz, _LT_pointer_compare()); 
 
       if (__temp == _S_free_list.end() || !_M_should_i_give(**__temp, 
       __sz)) 
         { 
           // We release the lock here, because operator new is 
           // guaranteed to be thread-safe by the underlying 
           // implementation. 
   #if defined __GTHREADS 
           __bfl_lock._M_unlock(); 
   #endif 
           // Try twice to get the memory: once directly, and the 2nd 
           // time after clearing the free list. If both fail, then 
           // throw std::bad_alloc(). 
           int __ctr = 2; 
           while (__ctr) 
             { 
               size_t* __ret = 0; 
               --__ctr; 
               try 
                 { 
                   __ret = reinterpret_cast<size_t*> 
                     (::operator new(__sz + sizeof(size_t))); 
                 } 
               catch(...) 
                 { 
                   this->_M_clear(); 
                 } 
               if (!__ret) 
                 continue; 
               *__ret = __sz; 
               return __ret + 1; 
             } 
           std::__throw_bad_alloc(); 
         } 
       else 
         { 
           size_t* __ret = *__temp; 
           _S_free_list.erase(__temp); 
   #if defined __GTHREADS 
           __bfl_lock._M_unlock(); 
   #endif 
           return __ret + 1; 
         } 
     } 
 
In the if-part, the function either (a) returns, from the while-loop; 
or (b) throws.  In the else-part, it does return. 
 
Please, fill a C++ front-end PR. 
 
-- Gaby 
PS: I would not mind removing the exception-specification from  
the function.  

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19343