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

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

[aj at gcc dot gnu dot org]

I see the following new warnings when compiling GCC CVS on different 
Linux platforms since 2004-01-05: 
../../../../libstdc++-v3/src/bitmap_allocator.cc: In member function 'size_t* 
__gnu_cxx::free_list::_M_get(size_t)': 
../../../../libstdc++-v3/src/bitmap_allocator.cc:110: warning: control reaches 
end of non-void function 
 
../../../../libstdc++-v3/testsuite/testsuite_abi.cc: In function ~symbol& 
get_symbol(const std::string&, const symbols&)~: 
../../../../libstdc++-v3/testsuite/testsuite_abi.cc:268: warning: control 
reaches end of non-void function

-- 
           Summary: New warnings in libstdc++-v3 since 2004-01-05
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aj at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *
  GCC host triplet: *
GCC target triplet: *


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

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

[aj 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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 15:58 -------
Hmm, is this at -O0 or -O2.  If the former then this is a dup of bug 16558.  If the later, then I don't 
know.

Please attach the preprocessed source (my last build did not have the warning).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
            Summary|New warnings in libstdc++-v3|[4.0 Regression] New
                   |since 2004-01-05            |warnings in libstdc++-v3
                   |                            |since 2004-01-05
   Target Milestone|---                         |4.0.0


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-09 16:46 -------
But I do get it on my daily builds on i686-openbsd3.1 starting on the 7th.
I will try to reduce this later today once I finish some homework and get some food.

-- 


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

[Bug middle-end/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05

[steven at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |middle-end
     Ever Confirmed|                            |1
  GCC build triplet|*                           |
   GCC host triplet|*                           |
 GCC target triplet|*                           |
   Last reconfirmed|0000-00-00 00:00:00         |2005-01-14 14:34:23
               date|                            |


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-14 14:45 -------
Actually this is not a middle-end after all.
The problem is that __throw_bad_alloc is not marked as noreturn as it should be.

"In the if-part, the function either (a) returns, from the while-loop; 
or (b) throws.  In the else-part, it does return. "

Yes it throws but since libstdc++ use a function call to throw, well GCC does not know that function 
can return since it is not marked as noreturn.

The patch which caused this warning:
2005-01-05  Benjamin Kosnik  <bkoz@redhat.com>
        * src/bitmap_allocator.cc: Use __throw_bad_alloc. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org,
                   |                            |gdr at gcc dot gnu dot org
          Component|middle-end                  |libstdc++


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-15 02:04 -------
Actually AJ's orginal analysis of the problem was right (and the same as mine):
"What is the best way to fix this?
Should we add to include/bits/functexcept.h some
__attribute__((noreturn)) ?"

He was talking about adding the noreturn on __throw_bad_alloc, not on _M_get itself.

-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-22 22:47 -------
*** Bug 19573 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu dot org


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

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

[pcarlini at suse dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-22 23:09 -------
I was about to send the following patch out for this.
Index: include/bits/functexcept.h
===============================================================
====
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/functexcept.h,v
retrieving revision 1.5
diff -u -p -r1.5 functexcept.h
--- include/bits/functexcept.h	24 Nov 2004 04:11:09 -0000	1.5
+++ include/bits/functexcept.h	22 Jan 2005 22:54:50 -0000
@@ -44,50 +44,50 @@ namespace std
 {
   // Helper for exception objects in <except>
   void
-  __throw_bad_exception(void);
+  __throw_bad_exception(void) __attribute__((noreturn));
 
   // Helper for exception objects in <new>
   void
-  __throw_bad_alloc(void);
+  __throw_bad_alloc(void) __attribute__((noreturn));
 
   // Helper for exception objects in <typeinfo>
   void
-  __throw_bad_cast(void);
+  __throw_bad_cast(void) __attribute__((noreturn));
 
   void
-  __throw_bad_typeid(void);
+  __throw_bad_typeid(void) __attribute__((noreturn));
 
   // Helpers for exception objects in <stdexcept>
   void
-  __throw_logic_error(const char* __s);
+  __throw_logic_error(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_domain_error(const char* __s);
+  __throw_domain_error(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_invalid_argument(const char* __s);
+  __throw_invalid_argument(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_length_error(const char* __s);
+  __throw_length_error(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_out_of_range(const char* __s);
+  __throw_out_of_range(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_runtime_error(const char* __s);
+  __throw_runtime_error(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_range_error(const char* __s);
+  __throw_range_error(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_overflow_error(const char* __s);
+  __throw_overflow_error(const char* __s) __attribute__((noreturn));
 
   void
-  __throw_underflow_error(const char* __s);
+  __throw_underflow_error(const char* __s) __attribute__((noreturn));
 
   // Helpers for exception objects in basic_ios
   void
-  __throw_ios_failure(const char* __s);
+  __throw_ios_failure(const char* __s) __attribute__((noreturn));
 } // namespace std
 
 #endif


-- 


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

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-22 23:16 -------
> I was about to send the following patch out for this.

Thanks Andrew, I have already implemented and tested AJ original suggestion, will
wait a bit for the list opinion.

-- 


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

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

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-23 01:52 -------
I think you need to spell it __noreturn__, as a user should be free to
#define noreturn
in the program, before the include.




-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-23 01:56 -------
(In reply to comment #8)
> > I was about to send the following patch out for this.
> 
> Thanks Andrew, I have already implemented and tested AJ original suggestion, will
> wait a bit for the list opinion.
Actually this patch was the same patch as what you did :).  Anyways makes sure that you take  Hans-
Peter's advice because it is correct (there was at least one bug report about this before but I had forgot 
about when writting the patch).

-- 


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

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-23 10:45 -------
Subject: Bug 19343

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	paolo@gcc.gnu.org	2005-01-23 10:45:01

Modified files:
	libstdc++-v3   : ChangeLog 
	libstdc++-v3/include/bits: functexcept.h 

Log message:
	2005-01-23  Paolo Carlini  <pcarlini@suse.de>
	Andreas Jaeger  <aj@suse.de>
	
	PR libstdc++/19343
	* include/bits/functexcept.h: Mark the helpers as 'noreturn'.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2867&r2=1.2868
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/functexcept.h.diff?cvsroot=gcc&r1=1.5&r2=1.6



-- 


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

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-23 10:46 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

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

[hp at gcc dot gnu dot org]

------- Additional Comments From hp at gcc dot gnu dot org  2005-01-24 00:17 -------
Do you *know* that this bug is fixed?
If so, I have to reopen PR 19573 as not being a duplicate of this bug after all;
I still see the failure.

-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-24 00:22 -------
(In reply to comment #13)
> Do you *know* that this bug is fixed?
> If so, I have to reopen PR 19573 as not being a duplicate of this bug after all;
> I still see the failure.

That is because I should have investigated PR 19573 a little more than closing it as a dup of this bug (I 
thought it was related to __throw_* but now after looking at the warnings and the code I know what it is 
a dup).  PR 19573 is really a dup of bug 19583 which has a reduced testcase and a patch already.

-- 


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

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-01-24 00:57 -------
> Do you *know* that this bug is fixed?

Of course: checked with a one week old (20050117) compiler. Now, unfortunately,
due to 19583 would be hard to tell: dozens and dozens of meaningless warnings
during the build of the library :-(

-- 


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