GCC 7.3 Is Being Released Next Month

[phoronix]

Phoronix: GCC 7.3 Is Being Released Next Month

Richard Biener of SUSE is preparing to release GCC 7.3 next month...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-7.3-In-January

[FireBurn]

I'm hoping the issue I had with GCC 7.1 & 7.2 has been fixed. GCC was generating bad 32bit code with march=native on my Skylake processor (or anything that uses BMI) that meant 32bit games wouldn't work with with radeonsi

Unfortunately I had no idea how to create a small test case https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763

[timofonic]

What I hope for 9+:

Infraestructure modernization:

- Code review: Able to comment code both in Pull/Merge
- More modern, flexible and powerful bug report system.
- Easier Merge/Pull Requests. Even over web interface.
- Proper Github/GitLab-like web interface to look at the code and integrated with the rest.
- Better documentation.
- Better webpage:
* More useful.
* More updated.
* Better design: It doesn't required to be filled with CSS. It just need to be somewhat cosmetically pleasant, wide web browser support, easier to navigate over it and take accesibility as priority (blind people, for example).
* More frequent updates.
* Use of a "planet" (blog aggregator).
* Consider to use a tool like GitLab, many project switched or are switching to it: Debian (WIP demo here, [url=https://gitlab.com/gitlab-org/gitlab-ce/issues/40541]GNOMEURL] (WIP but functional and used deployment here, VLC, Xiph.Org, Inkscape
Project:

- Make the source code extremely *A LOT MORE* friendly to newcomers: This is one of the main reasons developers prefer LLVM over GCC.
- Become really Open Governed and transparent over it: Now it looks like a CodeSourcery/RedHat product.
- Become part of the project more and better tools to automatize legacy code to be converted to new features as much and better as possible: Ancient code bases using old programming language versions, C to C++ refactorization (maybe Wine developerswould be happy about it).
- Research and develop in transpiling technologies that eventually become tools, useful for ease code refactoring to other languages, like porting a codebase to other languages: Java to C++, Python to C++, JavaScript to C++, Go to C++, C++ to Go, C++ to Rust, etc.
- Better debugging integration with other Open Source frameworks with compatible license.
- Make GCC JIT a lot more useful and become a LLVM drop-in replacement: Of course, it should replicate platform support of it too including GPUs (LLVM has BSD/MIT license? Can the code be reused?)
- Reconsider to merge back GCJ by finding interested reliable parties to maintain it. Add support for Java-dependent languages like Kotlin, Scala and others.
- Consider an agreement with ParrotVM project (unfortunately it isn't so much alive) to integrate it's technologies into th GCC ecosystem in the best benefical way for all parties. Consider it with other projects with potential but lack of manpower and infraestructure.
- Make the following language first class citizens in GCC: Go, Rust (because being only implemented in LLVM is bad for users and developers), Erlang, ADA (las I saw, ADA packages were for GCC 6.x in most distributions), D...

[mlau]

- Code review: Able to comment code both in Pull/Merge
- More modern, flexible and powerful bug report system.
- Easier Merge/Pull Requests. Even over web interface.
- Proper Github/GitLab-like web interface to look at the code and integrated with the rest.

If you really want to contribute, you're not going to be stopped by lack of web interfaces or the use of email.

- Better documentation.

Agree there.

- Better webpage:
* More useful.
* More updated.
* Better design: It doesn't required to be filled with CSS. It just need to be somewhat cosmetically pleasant, wide web browser support, easier to navigate over it and take accesibility as priority (blind people, for example).
* More frequent updates.

What's stopping you? Also, what does "more useful" mean? To me it's useful the way it is already.

* Use of a "planet" (blog aggregator).
* Consider to use a tool like GitLab, many project switched or are switching to it: Debian (WIP demo here, [url=https://gitlab.com/gitlab-org/gitlab-ce/issues/40541]GNOMEURL] (WIP but functional and used deployment here, VLC, Xiph.Org, Inkscape
Project:

Why, and why? I understand the hatred for SVN (have to use it at work, it sucks) and preferring git, but you don't need fancy web interfaces to contribute. I personally find them distracting and very cumbersome to use.

Again, what's stopping you from setting up this blog aggregator?

- Make the source code extremely *A LOT MORE* friendly to newcomers: This is one of the main reasons developers prefer LLVM over GCC.

What exactly does make a project " *A LOT MORE* friendly to newcomers"? Go read the code, find things you can make better, prepare a patch, submit it, get criticism for it and don't take it personally, improve patch, submit, repeat until accepted. That's the way the Linux kernel works, and most free/open source projects too.

- Become really Open Governed and transparent over it: Now it looks like a CodeSourcery/RedHat product.

That's because the most active developers (and incidentally also the ones that understand gcc best) are paid by them.
What does "Open Governed" mean?

- Become part of the project more and better tools to automatize legacy code to be converted to new features as much and better as possible: Ancient code bases using old programming language versions, C to C++ refactorization (maybe Wine developerswould be happy about it).
- Research and develop in transpiling technologies that eventually become tools, useful for ease code refactoring to other languages, like porting a codebase to other languages: Java to C++, Python to C++, JavaScript to C++, Go to C++, C++ to Go, C++ to Rust, etc.
- Better debugging integration with other Open Source frameworks with compatible license.

That reads like a hipster wish list. Also, double Bingo!

- Make GCC JIT a lot more useful and become a LLVM drop-in replacement: Of course, it should replicate platform support of it too including GPUs (LLVM has BSD/MIT license? Can the code be reused?)
- Reconsider to merge back GCJ by finding interested reliable parties to maintain it. Add support for Java-dependent languages like Kotlin, Scala and others.
- Consider an agreement with ParrotVM project (unfortunately it isn't so much alive) to integrate it's technologies into th GCC ecosystem in the best benefical way for all parties. Consider it with other projects with potential but lack of manpower and infraestructure.
- Make the following language first class citizens in GCC: Go, Rust (because being only implemented in LLVM is bad for users and developers), Erlang, ADA (las I saw, ADA packages were for GCC 6.x in most distributions), D...

What's stopping you from making these things happen?

I for one am happy with the work the gcc team does. GCJ was dropped due to nobody stepping up to maintain it. GCC has limited manpower, as it's not that hip and cool in the media like llvm, but the handful of developers working on it are doing an excellent job IMO.