Request for clarification regarding C++ version requirements in non-C++ frontends
Hi, I'm currently working on a branch of gccrs aiming to create some kind of Rust frontend within GCC. I've advanced to the stage where attempting to use pre-C++11 features is becoming inconvenient, particularly in the unique_ptr department. Part of the frontend AST is best expressed as vectors of pointers (due to polymorphism), and the gnu::unique_ptr clone of std::unique_ptr states it does not support standard containers like vector. I am aware that GCC currently has the policy of being compilable with a C++03 compiler, but I was wondering whether frontends other than the C and C++ ones are also subject to this restriction. For example, would it be acceptable if the frontend was written in C++11, given that it can still be compiled by g++? I see two other possible solutions if this restriction does in fact apply: If gnu::unique_ptr does in fact work with vector, I could simply use that. However, the lack of move semantics would lead to a very clunky kind of interface for the AST, which I would rather avoid, if possible. I could also use regular pointers, but this would make memory management more "clunky", so I would also prefer not to do so if possible. Perhaps just as importantly, the lack of move semantics would have performance implications - the deep copying of the vectors required to simplify memory management would be quite inefficient. Thanks, Theo
BountySource campaign for gcc PR/91851
Hello! For anyone who isn't aware of it yet, there is an ongoing BountySource campaign for gcc PR/91851 [1] which seeks to convert the m68k backend to MODE_CC so that it can be kept in gcc versions beyond version 11. The campaign is currently at $3,290 and can be found at [2]. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851 > [2] > https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Request for clarification regarding C++ version requirements in non-C++ frontends
On October 19, 2019 9:11:52 AM GMT+02:00, The Other wrote: >Hi, > >I'm currently working on a branch of gccrs aiming to create some kind >of >Rust frontend within GCC. I've advanced to the stage where attempting >to >use pre-C++11 features is becoming inconvenient, particularly in the >unique_ptr department. Part of the frontend AST is best expressed as >vectors of pointers (due to polymorphism), and the gnu::unique_ptr >clone of >std::unique_ptr states it does not support standard containers like >vector. > >I am aware that GCC currently has the policy of being compilable with a >C++03 compiler, but I was wondering whether frontends other than the C >and >C++ ones are also subject to this restriction. For example, would it be >acceptable if the frontend was written in C++11, given that it can >still be >compiled by g++? I think it is acceptable to write drontends not required for bootstrapping in any language GCC supports itself. Richard. >I see two other possible solutions if this restriction does in fact >apply: > >If gnu::unique_ptr does in fact work with vector, I could simply use >that. >However, the lack of move semantics would lead to a very clunky kind of >interface for the AST, which I would rather avoid, if possible. > >I could also use regular pointers, but this would make memory >management >more "clunky", so I would also prefer not to do so if possible. Perhaps >just as importantly, the lack of move semantics would have performance >implications - the deep copying of the vectors required to simplify >memory >management would be quite inefficient. > >Thanks, >Theo
gcc-9-20191019 is now available
Snapshot gcc-9-20191019 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20191019/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-9-branch revision 277205 You'll find: gcc-9-20191019.tar.xzComplete GCC SHA256=5782781bcb7682850d1f7b89642cfeede7a7af5b86b155b7b5b04f4d67798034 SHA1=4af9d6334a5a33a8764445023ba2c419835fadc5 Diffs from 9-20191012 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
