On 9/2/18 10:26 AM, Gerald Pfeifer wrote:
Jason and Nathan,

while I completed one C+ non-bug entry with the patch below, I am
not sure the items as such is really still relevant?

In fact, if you could have a look at https://gcc.gnu.org/bugs/#nonbugs_cxx
and advise which entries perhaps should be removed (or updated or
added), I'll take care.

sorry for the tardiness.

1) export
exported templates were removed as a feature in C++11. 'export' remains a reserved keyword. It is being recycled for C++ modules, currently an experimental TS.

2) G++ emits two copies of constructors and destructors.
IIUC the ABI has been corrected to allow a single cdtor in cases where they are the same. We emit compatibility(?) aliases on targets that support them. Jason?

3) Global destructors are not run in the correct order.
I think --use-cxa-atexit is enabled by default on most (nearly all) targets these days.

4) Classes in exception specifiers must be complete types.
While this is still correct, exception specifiers were deprecated in C++11. They were removed in C++17. We still support them for compatibility. Modern code should use noexcept, or noexcept(boolean-constant-expression)

5) Exceptions don't work in multithreaded applications.
Correct, but as with cxa-atexit, usually enabled by default on threading systems

6) Templates, scoping, and digraphs.
again, correct, but we give a very clueful diagnostic:
digraph.cc:8:2: error: ‘<::’ cannot begin a template-argument list [-fpermissive]
 B<::X::A> *p;
  ^~
digraph.cc:8:2: note: ‘<:’ is an alternate spelling for ‘[’. Insert whitespace between ‘<’ and ‘::’ digraph.cc:8:2: note: (if you use ‘-fpermissive’ or ‘-std=c++11’, or ‘-std=gnu++11’ G++ will accept your code)

7) Copy constructor access check while initializing a reference.
This example is no longer correct, it compiles without error (including c++98 mode). I think compilers now have to know about about-to-die temporaries and move them?

8) ABI changes
We should probably document the std-forced ABI changes?

Hope that helps.

nathan



--
Nathan Sidwell

Reply via email to