Re: GCC association with the FSF
On 4/13/2021 12:01 AM, Richard Biener via Gcc wrote: On Mon, Apr 12, 2021 at 11:24 PM Nathan Sidwell wrote: On 4/12/21 5:32 AM, Richard Biener via Gcc wrote: Please concentrate on the important things, we're supposed to get a release of GCC 11 out of the door. Then it is important this is resolved. Maybe - but it is very apparent that the current "discussion" will lead nowhere. I would disagree with that Richi. While there are elements in this discussion that are unhelpful, the overall question about GCC association with the FSF and GNU is a good one to be working through. An EGCS-like split like we had in the late 90s is, IMHO, a definite possibility here and judging the mood of the GCC development community is vital to guiding decisions we need to make as a project. Jeff . Without strong support from the development community splits like that aren't likely to be successful. And to be clear, what *I* will be looking at is how those doing the real work respond, not the ramblings of folks who
Re: libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
Sorry for the slow reply ... On Mon, 1 Feb 2021 at 22:59, Gerald Pfeifer wrote: > > I noticed this section on "Backwards Compatibility" in the libstdc++ > docs that talks about > > - glibc 2.0.x > - GCC 3.2 (August 2002) > - GCC 4.1 (February 2006) > > and links to "Migrating to GCC 4.1" and "Migration guide for GCC-3.2" > documents. > > Does this still make sense (and serve real users or developers) or > should this be trimmed quite a bit? Yeah, that (and a lot more) should be trimmed from the libstdc++ manual. It's just time consuming to do it.
Re: libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
On 13/04/21 16:19 +0100, Jonathan Wakely via Libstdc++ wrote: Sorry for the slow reply ... On Mon, 1 Feb 2021 at 22:59, Gerald Pfeifer wrote: I noticed this section on "Backwards Compatibility" in the libstdc++ docs that talks about - glibc 2.0.x - GCC 3.2 (August 2002) - GCC 4.1 (February 2006) and links to "Migrating to GCC 4.1" and "Migration guide for GCC-3.2" documents. Does this still make sense (and serve real users or developers) or should this be trimmed quite a bit? Yeah, that (and a lot more) should be trimmed from the libstdc++ manual. It's just time consuming to do it. It turned out to be pretty easy in this case, as the ancient text was so obviously useless now that it can just be ripped out. The remaining parts of the page should probably be evaluated too, but at least the truly prehistoric stuff is gone with this patch. Pushed to trunk. commit 989e512f719a44fafca0030d7b8a1f5bf5f1baf7 Author: Jonathan Wakely Date: Tue Apr 13 16:30:16 2021 libstdc++: Remove outdated docs on libg++ and libstdc++-v2 The libstdc++-v3 manual doesn't need to document how to use its predecessors. libstdc++-v3/ChangeLog: * doc/xml/manual/backwards_compatibility.xml: Remove porting notes for libg++ and libstdc++-v2, and bibliography. * doc/html/*: Regenerated. diff --git a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml index cce553380e1..6a4a5ccedfb 100644 --- a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml +++ b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml @@ -22,7 +22,7 @@ dinosaur. Some background: libg++ was designed and created when there was no ISO standard to provide guidance. Classes like linked lists are now -provided for by listand do not need to be +provided for by std::list and do not need to be created by genclass. (For that matter, templates exist now and are well-supported, whereas genclass (mostly) predates them.) @@ -34,41 +34,13 @@ Committee couldn't include everything, and so a lot of those obvious classes didn't get included. -Known Issues include many of the limitations of its immediate ancestor. - -Portability notes and known implementation limitations are as follows. - -No ios_base - - - At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. +That project is no longer maintained or supported, and the sources +archived. For the desperate, the +http://www.w3.org/1999/xlink"; xlink:href="https://ftp.gnu.org/old-gnu/libg++/";>ftp.gnu.org +server still has the libg++ source. -No cout in , no cin in - - - - In earlier versions of the standard, - , - - and - used to define - cout, cin and so on. ISO C++ specifies that one needs to include - - explicitly to get the required definitions. - - Some include adjustment may be required. - -This project is no longer maintained or supported, and the sources -archived. For the desperate, -the http://www.w3.org/1999/xlink"; xlink:href="http://gcc.gnu.org/extensions.html";>GCC extensions -page describes where to find the last libg++ source. The code is -considered replaced and rewritten. - - - - Second @@ -80,504 +52,14 @@ considered replaced and rewritten. - The STL portions of this library are based on SGI/HP STL release 3.11. + The STL portions of that library are based on SGI/HP STL release 3.11. - This project is no longer maintained or supported, and the sources - archived. The code is considered replaced and rewritten. + That project is no longer maintained or supported, and the sources + archived. The code was replaced and rewritten for libstdc++-v3. - - Portability notes and known implementation limitations are as follows. - - -Namespace std:: not supported - - - -Some care is required to support C++ compiler and or library -implementation that do not have the standard library in -namespace std. - - - -The following sections list some possible solutions to support compilers -that cannot ignore std::-qualified names. - - - -First, see if the compiler has a flag for this. Namespace -back-portability-issues are generally not a problem for g++ -compilers that do not have libstdc++ in std::, as the -compilers use -fno-honor-std (ignore -std::, :: = std::) by default. That is, -the responsibility for enabling or disabling std:: is -on the user; the maintainer does not have to care about it. This -probably applies to some other compilers as well. - - - -Second, experiment with a variety of pre-processor tricks. - - - -By defining std as a macro, fully-qualified namespace -calls become global. Volia. - - - -#ifdef WICKEDLY_OLD_COMPILER -# define std -#endif - - - -Thank
Re: libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
On 13/04/21 16:37 +0100, Jonathan Wakely wrote: On 13/04/21 16:19 +0100, Jonathan Wakely via Libstdc++ wrote: Sorry for the slow reply ... On Mon, 1 Feb 2021 at 22:59, Gerald Pfeifer wrote: I noticed this section on "Backwards Compatibility" in the libstdc++ docs that talks about - glibc 2.0.x - GCC 3.2 (August 2002) - GCC 4.1 (February 2006) and links to "Migrating to GCC 4.1" and "Migration guide for GCC-3.2" documents. Does this still make sense (and serve real users or developers) or should this be trimmed quite a bit? Yeah, that (and a lot more) should be trimmed from the libstdc++ manual. It's just time consuming to do it. It turned out to be pretty easy in this case, as the ancient text was so obviously useless now that it can just be ripped out. The remaining parts of the page should probably be evaluated too, but at least the truly prehistoric stuff is gone with this patch. Pushed to trunk. Oops, I meant to change gcc@ to gcc-patches@ before sending, sorry for the noise on the main list. commit 989e512f719a44fafca0030d7b8a1f5bf5f1baf7 Author: Jonathan Wakely Date: Tue Apr 13 16:30:16 2021 libstdc++: Remove outdated docs on libg++ and libstdc++-v2 The libstdc++-v3 manual doesn't need to document how to use its predecessors. libstdc++-v3/ChangeLog: * doc/xml/manual/backwards_compatibility.xml: Remove porting notes for libg++ and libstdc++-v2, and bibliography. * doc/html/*: Regenerated. diff --git a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml index cce553380e1..6a4a5ccedfb 100644 --- a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml +++ b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml @@ -22,7 +22,7 @@ dinosaur. Some background: libg++ was designed and created when there was no ISO standard to provide guidance. Classes like linked lists are now -provided for by listand do not need to be +provided for by std::list and do not need to be created by genclass. (For that matter, templates exist now and are well-supported, whereas genclass (mostly) predates them.) @@ -34,41 +34,13 @@ Committee couldn't include everything, and so a lot of those obvious classes didn't get included. -Known Issues include many of the limitations of its immediate ancestor. - -Portability notes and known implementation limitations are as follows. - -No ios_base - - - At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. +That project is no longer maintained or supported, and the sources +archived. For the desperate, the +http://www.w3.org/1999/xlink"; xlink:href="https://ftp.gnu.org/old-gnu/libg++/";>ftp.gnu.org +server still has the libg++ source. -No cout in , no cin in - - - - In earlier versions of the standard, - , - - and - used to define - cout, cin and so on. ISO C++ specifies that one needs to include - - explicitly to get the required definitions. - - Some include adjustment may be required. - -This project is no longer maintained or supported, and the sources -archived. For the desperate, -the http://www.w3.org/1999/xlink"; xlink:href="http://gcc.gnu.org/extensions.html";>GCC extensions -page describes where to find the last libg++ source. The code is -considered replaced and rewritten. - - - - Second @@ -80,504 +52,14 @@ considered replaced and rewritten. - The STL portions of this library are based on SGI/HP STL release 3.11. + The STL portions of that library are based on SGI/HP STL release 3.11. - This project is no longer maintained or supported, and the sources - archived. The code is considered replaced and rewritten. + That project is no longer maintained or supported, and the sources + archived. The code was replaced and rewritten for libstdc++-v3. - - Portability notes and known implementation limitations are as follows. - - -Namespace std:: not supported - - - -Some care is required to support C++ compiler and or library -implementation that do not have the standard library in -namespace std. - - - -The following sections list some possible solutions to support compilers -that cannot ignore std::-qualified names. - - - -First, see if the compiler has a flag for this. Namespace -back-portability-issues are generally not a problem for g++ -compilers that do not have libstdc++ in std::, as the -compilers use -fno-honor-std (ignore -std::, :: = std::) by default. That is, -the responsibility for enabling or disabling std:: is -on the user; the maintainer does not have to care about it. This -probably applies to some other compilers as well. - - - -Second, experiment with a variety of pre-processor tricks. - -
Re: Default debug format for AVR
Agreed. I'd bet AIX is the outlier here and that most, if not all, other ports that may currently be stabs-by-default can switch to dwarf-by-default with no significant fallout. So we fix everything we can while we wait for AIX to move forward. I am not requesting a continuation of support for STABS to be obstinate. AIX has some support for DWARF, but STABS continues to be the primary debug format on AIX. Binutils does not fully function on AIX and the AIX native tools support for DWARF is incomplete. Also, AIX uses XCOFF file format, not ELF, so DWARF syntax needs to be adapted and all of the tools need to agree on the way that AIX symbols are represented in DWARF. Just to be clear, I didn't think you were being obstinate at all. I was just pointing out that I think the other ports can and probably should change now (well, start of gcc-12 cycle), but that AIX can't yet. Jeff
Re: GCC association with the FSF
On 13.04.21 16:40, Jeff Law via Gcc wrote: An EGCS-like split like we had in the late 90s is, IMHO, a definite possibility here Such a move would, in all probability, leave both parts of the split GCC with too few developers to compete against LLVM, thus rendering GCC irrelevant and ruining an important project for free software. (I don't like the idea, for the record).
Re: GCC association with the FSF
On 4/13/2021 10:52 AM, Thomas Koenig wrote: On 13.04.21 16:40, Jeff Law via Gcc wrote: An EGCS-like split like we had in the late 90s is, IMHO, a definite possibility here Such a move would, in all probability, leave both parts of the split GCC with too few developers to compete against LLVM, thus rendering GCC irrelevant and ruining an important project for free software. (I don't like the idea, for the record). I'm not sure there'll be that much of a community split. Based on what I've seen *so far* it'd be less of a split than we had with EGCS. But that's precisely why I want folks to chime in, particularly those doing the day-to-date development work -- I want to see what the likely impact on the development community would be rather than going with just what *I* want. jeff
Re: GCC association with the FSF
On 13.04.21 19:19, Jeff Law via Gcc wrote: I'm not sure there'll be that much of a community split. Based on what I've seen *so far* it'd be less of a split than we had with EGCS. But that's precisely why I want folks to chime in, particularly those doing the day-to-date development work -- I want to see what the likely impact on the development community would be rather than going with just what *I* want. If such a split were to occur, it would probably cost you gfortran. We're in a precarious situation as is. So, goodbye to SPEC for both branches in the medium term.
Re: GCC association with the FSF
On 4/13/2021 11:32 AM, Thomas Koenig via Gcc wrote: On 13.04.21 19:19, Jeff Law via Gcc wrote: I'm not sure there'll be that much of a community split. Based on what I've seen *so far* it'd be less of a split than we had with EGCS. But that's precisely why I want folks to chime in, particularly those doing the day-to-date development work -- I want to see what the likely impact on the development community would be rather than going with just what *I* want. If such a split were to occur, it would probably cost you gfortran. We're in a precarious situation as is. Hmm, I'm not following gfortran closely. Is there a reason to believe that the gfortran developers would split across the two projects? If so, that's a significant issue. If you've got a pointer to a discussion, I'm happy to take it and read up on things. So, goodbye to SPEC for both branches in the medium term. That depends, of course. Jeff
Re: My 2nd attempt to devel for gcc
Hello, Sorry for slight delay. Very happy if i could prepare prototype of this solution. My best guess is if we could hookify all target code everything callable either from frontends or midend, we could try to severly cut this estimate. I also went back to thread you memtioned, i underestimated time for making gcc driver multitarget and likewise for collect binary. What also puzzles me is work on multilib, i still understand multilib clearly enough. In my previous rant i focused mostly on compiler main exec and making it multitarget. We should if this project makes any or some sense think of how configure flags influence codegen of target sources. Im not 100% sure here. If running such project, id focus first on hookifying and possibly wrapping in functions all target genned and callable code. Then id try to make gcc driver multitarget, then same for collect then same for multilib and in the end for gcc main frontend-specific exec ie interface between midend and target and switching configure to gen all code for all targets selected. If still interested and if i should go to clarifying and researching making driver collect multilib multitarget, please let me know. Also if what i say doesnt make much sense, please also let me know. Best regards, Pawel kunio pon., 29.03.2021, 19:25 użytkownik Joseph Myers napisał: > On Sun, 28 Mar 2021, pawel k. via Gcc wrote: > > > Hello, > > I would like to ask whether there would be interest in the project to be > > able to build a single binary of gcc where target would be selectable > with > > option flags ie more than one target could be included and aimed for by > > single binary. > > > > If so i could try myself at adding such feature to gcc. It looks > ambitious > > but doable. > > I've estimated this as taking about two person-years of work (that is, two > person-years of work for someone with extensive experience in GCC > development). > > https://gcc.gnu.org/legacy-ml/gcc-patches/2010-06/msg02675.html > > While there have, for example, been various conversions of target macros > to hooks, and other such similar changes, since then, I don't think > anything fundamentally changes the basic estimate. > > -- > Joseph S. Myers > jos...@codesourcery.com >
On rms controversy
Hello, Im multiyear gcc user on many targets. I love the project and wish it all the best. Im also senior c/cpp and linux sw devel with 20 years of experience. Im observing an rms controversy from some perspective and here are my thoughts: -you didnt base attack on real data but allegations. Additionally falsified ones. -nobody asked rms whether he retracts and indeed he does on some and clarify on others. -part of fsf is rotten by far left mental virus parasite. See gad saads book on the topic. -basically rms didnt do what he was alleged he did. -nobody gave him way to defend like in legal process. -he is back and he should stay. -those who attacked him baselessly and thoughtlessly should disappear in shame and their names should be on gcc and fsf front pages linked shamelist. -rms is heavily autistic as some may know and he might not have perfect judgmental powers over his words. -last but not least all far left snowflakes of you assuming guilt and barring one from defence, please f off and f you for now. -possibly some of you wanted to steal his project so as per above big f off and f you. That would be it. Best regards, Pawel kunio
Re: GCC association with the FSF
On 14.04.21 01:41, Jeff Law wrote: On 4/13/2021 11:32 AM, Thomas Koenig via Gcc wrote: On 13.04.21 19:19, Jeff Law via Gcc wrote: I'm not sure there'll be that much of a community split. Based on what I've seen *so far* it'd be less of a split than we had with EGCS. But that's precisely why I want folks to chime in, particularly those doing the day-to-date development work -- I want to see what the likely impact on the development community would be rather than going with just what *I* want. If such a split were to occur, it would probably cost you gfortran. We're in a precarious situation as is. Hmm, I'm not following gfortran closely. Is there a reason to believe that the gfortran developers would split across the two projects? There is no discussion at the moment. Most people on the fortran mailing list do not follow gcc. I know of at least two contributors (myself incluced) who would in all probability stop contributing in that case. But then again, I'm only the currently active contributor with the longest service history (since 2005), so my contribution may not matter much. You can, of course, raise the issue on the gfortran mailing list. This will poison it with the same discussion that has poisoned the gcc mailing list. There is an even chance that this will lead people to stop contributing already. If so, that's a significant issue. If you've got a pointer to a discussion, I'm happy to take it and read up on things. Well, just raise the issue. I will, in that case, I will certainly add my opinion.
