Handling gcc's noexcept-type warning

exception handling
handler requires an exception declaration
gcc no-exceptions
exception handling in c
exception handling guidelines
disable exception handling c++
c++ try-catch finally
error and exception handling

Consider this example, from bug 80985:

template <class Func>
void call(Func f)
{
    f();
}

void func() noexcept { }

int main()
{
    call(func);
}

Compiling this with all warnings enabled, as you do, yields:

$ g++ -std=c++14 -Wall foo.cxx 
foo.cxx:2:6: warning: mangled name for ‘void call(Func) [with Func = void (*)() noexcept]’ will change in C++17 because the exception specification is part of a function type [-Wnoexcept-type]
 void call(Func f)
      ^~~~

What exactly am I supposed to do with this warning? What is the fix?

There's several things you can do about the warning message.

Disable it with -Wno-noexcept-type. In many projects the warning message is unhelpful because there's no chance the resulting object will be linked with an another object that expects it to use GCC's C++17 name mangling. If you're not compiling with different -std= settings and you're not building a static or shared library where the offending function is part of its public interface then the warning message can safely disabled.

Compile all your code with -std=c++17. The warning message will go away as the function will use the new mangled name.

Make the function static. Since the function can no longer be referenced by another object file using a different mangling for the function the warning message will not be displayed. The function definition will have to be included in all compilation units that use it, but for template functions like in your example this is common anyways. Also this won't work for member functions were static means something else.

When calling a function template specify the template parameter explicitly giving a compatible function pointer type that doesn't have the exception specification. For example call<void (*)()>(func). You should also be able to use cast to do this as well, but GCC 7.2.0 still generates a warning even though using -std=c++17 doesn't change the mangling.

When the function isn't a template don't use noexcept with any function pointer types used in the function's type. This and the last point rely on the fact that only non-throwing function pointer types result in naming mangling changes and that non-throwing function pointers can be assigned (C++11) or implicitly converted (C++17) to possibly throwing function pointers.

Exceptions, By allowing exception objects to propagate, a more flexible approach to error handling is made possible (although not required.) Instead of dealing with an error� In many projects the warning message is unhelpful because there's no chance the resulting object will be linked with an another object that expects it to use GCC's C++17 name mangling. If you're not compiling with different -std= settings and you're not building a static or shared library where the offending function is part of its public interface then the warning message can safely disabled.

I'm upvoting Ross's answer for the call<void (*)()>(func) solution. It explicitly tells the compiler that you want the template instantiated for a non-noexcept function type, and guarantees that your code will operate exactly the same in C++17 as it did in C++14.

More alternatives are:

(1) Wrap the noexcept function in a lambda (which isn't noexcept):

template <class Func>
void call(Func f)
{
    f();
}

void func() noexcept { }

int main()
{
    call([]() { func(); });
}

(2) Create a separate wrapper function without noexcept. This is more typing initially, but if you have multiple call sites it could save typing overall. This is what I ended up doing in the code that originally prompted me to file the GCC bug.

GCC C++ Exception Handling Implementation, .eh_frame layout is described briefly in the LSB documentation. Ian Lance Taylor (author of the gold linker) also made some blog posts on .eh_frame and� GCC is Government Community Cloud instance is one of the environments which provides access to government Community Cloud for public sector organizations and contractor organizations servicing them. The main difference between them is the US Gov / DoD compliance standards that they confirm to.

In addition to what is already said, I have found another way to get rid of this warning in GCC 7. Apparently, GCC generates this warning if and only if the first instantiation of call() involves noexcept. So a solution would be first to instantiate call() with a not noexcept function.

This trick would also do:

using dummy = decltype(call(std::declval<void(*)()>()));

P.S. GCC 8.2.1 does not report a warning in this case.

C++ exception handling internals – An infinite monkey – Nico , And sure enough, gcc complains about missing C++ symbols. Reading some linker errors we deduced last time that for handling exceptions we need help� 24.3.1 Basic Signal Handling. The signal function provides a simple interface for establishing an action for a particular signal. The function and associated macros are declared in the header file signal.h. Data Type: sighandler_t. This is the type of signal handler functions.

The issue they are warning you about is that in C++14, this will work:

void call(void (*f)())
{
    f();
}

void func() noexcept {}

int main(int argc, char* argv[])
{
    call(&func);
    return 0;
}

but in C++17, you would need to change the declaration of call to be:

void call(void (*f)() noexcept)
{
    f();
}

Since you have defined call to be a template, you don't need to worry about this. Still, it could cause you problems because the inferred type is changing, which doesn't usually happen.

For example, this code will compile in C++14 but not C++17:

void foo() noexcept {}
void bar()          {}

template <typename F>
void call(bool b, F f1, F f2)
{
    if (b)
        f1();
    else
        f2();
}

void foobar(bool b)
{
    call(b, &foo, &bar);
}

In C++14, the types of foo and bar are the same, but they are different in C++17, meaning the template resolution will fail. The error message in gcc 7.2 with the flag -std=c++1z is:

note:   template argument deduction/substitution failed:
note:   deduced conflicting types for parameter 'F' ('void (*)() noexcept' and 'void (*)()')

In the example you've given, there is no issue and you won't have a problem compiling in C++14 or C++17 mode. If the code is more complex than the example here (e.g. similar to the examples I gave above), you could encounter some compiler problems. It seems you have a recent compiler; try compiling with -std=c++1z and see if there are warnings or errors.

How does gcc implement C++ exception handling?, GCC follows the zero-cost strategy for exception handling, as described in the Itanium ABI. The Itanium ABI Exception Handling Specification defines a� It discusses how to contribute to GCC (see Contributing), the characteristics of the machines supported by GCC as hosts and targets (see Portability), how GCC relates to the ABIs on such systems (see Interface), and the characteristics of the languages for which GCC front ends are written (see Languages). It then describes the GCC source tree structure and build system, some of the interfaces to GCC front ends, and how support for a target system is implemented in GCC.

gcc(1) - Linux manual page - Michael Kerrisk, GCC normally generates special code to handle certain built-in functions - fopenacc Enable handling of OpenACC directives "#pragma acc" in C/C++ and� Signal Handling (The GNU C Library) Next: Program Basics, Previous: Non-Local Exits, Up: Top [Contents][Index] 24 Signal Handling. A signalis a software interrupt delivered to a process. Theoperating system uses signals to report exceptional situations to anexecuting program. Some signals report errors such as references toinvalid memory addresses; others report asynchronous events, such asdisconnection of a phone line.

Exception handling issue using gcc for shared libraries, Back to forums home. Exception handling issue using gcc for shared libraries. GCCAIX. pholditch. 20 May 2019 ( a year ago ). Given this simple C++ program:. Certification means the issuance of a written General Certificate of Conformity (GCC) in which the manufacturer or importer certifies that its non-children's (general use) product complies with all applicable consumer product safety rules (or similar rules, bans, standards, or regulations under any law enforced by the Commission for that product.)

GCC: Handling Difficult People, Global Communication Center Workshop: Team Communication Part II: Handling Difficult People and Situations. WHEN: Mar. 1, 5 - 6 p.m.; WHERE: Ideate� Exception handling overhead can be measured in the size of the executable binary, and varies with the capabilities of the underlying operating system and specific configuration of the C++ compiler. On recent hardware with GNU system software of the same age, the combined code and data size overhead for enabling exception handling is around 7%.

Comments
  • If call is entirely internal to your project, it doesn’t matter. It only matters in cases where two different translation units use it, where one was compiled with C++17 and one wasn’t. Even then, since call is a template function, it probably won’t have that big an impact other than having an extra definition in the final executable.
  • @DanielH Not that I mean to speak for Barry, above, but if you are compiling a project with -wError, then that "innocuous warning" will cause the program to not compile at all, despite being correct. That matters.
  • @markt1964 In the post only -Wall is used. If you compile with -Werror or try to avoid compiler errors (which is a good idea), then yes, you'll have a problem. One that might, perhaps, best be addressed by adding -Wno-noexcept-type, depending on circumstances.
  • @Barry, do you rebuild your project from scratch (and all its users) when you switch compiler versions?
  • Just a note, but there might be less of this warning in GCC8. Not sure whether it applies to your specific case though.
  • This doesn't answer the question. I'm aware of the addition of noexcept to the type system.
  • I added more explanation at the end; hopefully that clarifies the issue