Bug 101130 - Broken backward compatibility after __attribute__-noexcept order change
Summary: Broken backward compatibility after __attribute__-noexcept order change
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 11.1.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic, rejects-valid
Depends on:
Blocks:
 
Reported: 2021-06-18 21:46 UTC by alex
Modified: 2021-06-21 06:27 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description alex 2021-06-18 21:46:53 UTC
Testcase:

void f() {
   []() __attribute__((__noinline__)) noexcept {
      void g() noexcept; g(), g();
   }();
}

This started to produce (3!) syntax error messages in g++9.1 whereas g++8.5 and below accept them and do the expected thing.

The new accepted syntax is:

void f() {
   []() noexcept __attribute__((__noinline__)) {
      void g() noexcept; g(), g();
   }();
}

I do not know whether the change was on purpose, and apparently it has to do with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503. As to the backward compatibility, I do not know whether many users actually depend on it, but at least my codebase does depend on this nice trick (to force object code deduplication for slow paths). The problem is that all versions of clang++ still accept the old syntax and so this affects compiler independence (icpc accepts both since much time ago), so maybe I should open the bug on them;-) Using the standard C++ attributes [[__gnu__::__noinline__]] is also not an option since as a warning message states for both g++ and clang++ and the assembly output evidences, this applies to the application operator type, not to the operator itself and so does nothing (a solution is proposed for C++2b).
Comment 1 Jonathan Wakely 2021-06-18 22:09:27 UTC
It was changed by the r265787 fix for PR 60503, but maybe that should only have been for C++11-style attributes not GNU ones.