[Bug c++/57632] New: Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)

[Bug c++/57632] New: Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)

[basv@odd-e.com]

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

            Bug ID: 57632
           Summary: Operator new overloads with stdc++11 enabled looses
                    exception specifier (MacOsX)
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: basv@odd-e.com

G++ on MacOsX acts different when enabling the new c++11 related to operator
new overloads. If I compile the following code:

#include "stdlib.h"
#include <new>

void* operator new(size_t mem) throw(std::bad_alloc);
void* operator new(size_t mem) throw(std::bad_alloc);

Then when compiling g++ new.cpp, it compiles fine.
But when I compile g++ -std=c++11 new.cpp, then it results in this error:

new.cpp:6:52: error: declaration of ‘void* operator new(size_t) throw
(std::bad_alloc)’ has a different exception specifier
 void* operator new(size_t mem) throw(std::bad_alloc);
                                                    ^
new.cpp:5:7: error: from previous declaration ‘void* operator new(std::size_t)’
 void* operator new(size_t mem) throw(std::bad_alloc);
       ^
------------

I've not been able to replicate this under linux and digging into it a bit, it
seems to relate to the c++config.h definitions of _GLIBCXX_THROW.
>From gcc-bugs-return-424515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 17 06:48:50 2013
Return-Path: <gcc-bugs-return-424515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30775 invoked by alias); 17 Jun 2013 06:48:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30107 invoked by uid 48); 17 Jun 2013 06:48:43 -0000
From: "jbeulich at novell dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/53425] No warnings are given for -mno-sse
Date: Mon, 17 Jun 2013 06:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jbeulich at novell dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-53425-4-R0sLLe9d2d@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53425-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53425-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00894.txt.bz2
Content-length: 686

http://gcc.gnu.org/bugzilla/show_bug.cgi?idS425

jbeulich at novell dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbeulich at novell dot com

--- Comment #4 from jbeulich at novell dot com ---
I don't think this is quite right for 32-bit: For one, MMX types should be
handled separately in that case. And there are now two warnings for both MMX
and SSE types, i.e. the new one is redundant with the ones generated by
function_arg_32(). I believe all that's needed is adding TARGET_64BIT to the
conditional in type_natural_mode().

[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
This happens on Linux too. The issue is that per C++11 (see 18.6) operator new
is declared in <new> as:

  void* operator new(size_t mem);                  (1)

and as such is internally pre-declared in decl.c:cxx_init_decl_processing.
Then, if I understand correctly, when the parser sees in user code:

  void* operator new(size_t mem) throw(std::bad_alloc);

it thinks, Ok the user is just redeclaring (1), it simply ignores the exception
specifier. Then the additional declaration in user code is seen inconsistent
with the former one (it becomes clear that the exception specifier was dropped
the first time).

We (used to) have a completely similar, dual, issue in C++98 for this user
code:

void* operator new(std::size_t mem);
void* operator new(std::size_t mem);

and I'm not sure whether and how we want to do better.

Note that changing in C++11 the user code to:

void* operator new(std::size_t mem);
void* operator new(std::size_t mem);

is perfectly fine.

[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So the defect report against C++ was closed as not a defect:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#967 .
The related one
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1948 dealing with
noexcept was also closed as not a defect.


So GCC is correct, There is no bug here.

[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-01-07
             Status|RESOLVED                    |NEW

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I agree with comment 3 that the current diagnostic is poor:

#include <new>
void* operator new(std::size_t mem) throw(std::bad_alloc);
void* operator new(std::size_t mem) throw(std::bad_alloc);


g++ -std=c++11  -c new.cc -Wno-deprecated
new.cc:3:7: error: declaration of ‘void* operator new(std::size_t) throw
(std::bad_alloc)’ has a different exception specifier
    3 | void* operator new(std::size_t mem) throw(std::bad_alloc);
      |       ^~~~~~~~
new.cc:2:7: note: from previous declaration ‘void* operator new(std::size_t)’
    2 | void* operator new(std::size_t mem) throw(std::bad_alloc);
      |       ^~~~~~~~


Why does it accept the incorrect exception specification on line 2, but then
give an error for an identical one on line 3? Why do we refer to line 2 in the
note and say it's different, when it's not?

Paolo's explanation in comment 1 doesn't make the behaviour correct, it just
explains why we behave like that. Either both redeclarations should be valid or
neither should be valid.

So I think either we should either:

- accept both redeclarations (as Clang does), or

- give a diagnostic (maybe a pedwarn) for the first redeclaration because it
doesn't match the one in <new> (and the implicit one predefined by the
compiler), and fix the diagnostic to refer to the previous declaration in <new>
instead of the one on line 2.

[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> I agree with comment 3 that the current diagnostic is poor:

Oh I missed that.

> 
> #include <new>
> void* operator new(std::size_t mem) throw(std::bad_alloc);
> void* operator new(std::size_t mem) throw(std::bad_alloc);
> 
> 
> g++ -std=c++11  -c new.cc -Wno-deprecated
> new.cc:3:7: error: declaration of ‘void* operator new(std::size_t) throw
> (std::bad_alloc)’ has a different exception specifier
>     3 | void* operator new(std::size_t mem) throw(std::bad_alloc);
>       |       ^~~~~~~~
> new.cc:2:7: note: from previous declaration ‘void* operator new(std::size_t)’
>     2 | void* operator new(std::size_t mem) throw(std::bad_alloc);
>       |       ^~~~~~~~
> 

Reduced testcase for that:
void f(void);
void f(void) throw(int);
void f(void) throw(int);

Noexcept has the same issue:
void g(void);
void g(void) noexcept;
void g(void) noexcept;

I suspect what happens is the following when we merge the two decls we chose
the new decl for the location but we remove the exception specifier/noexcept
(confirmed by swapping the first two decls and seeing the error again).

[Bug c++/57632] diagonistic for different exception specifier/noexcept if decl is declared twice should be improved

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> Reduced testcase for that:
> void f(void);
> void f(void) throw(int);
> void f(void) throw(int);
> 
> Noexcept has the same issue:
> void g(void);
> void g(void) noexcept;
> void g(void) noexcept;

It is even worse when the first declaration is in a system header file, the
second declaration does not cause an error during merging but then we lose the
throw/noexcept but have the line number of the second decl so when we go and
merge in the third decl, we do the error message that way.