[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #29 from bkoz at gcc dot gnu dot org 2008-01-18 08:35 --- I asked for two votes: 1) keep removal of pre-iso includes, (ie current sources). Majority approves. 2) reinstate just iostream.h and fstream.h. Majority declines. Therefore, I am closing this as WONTFIX as per Richard's suggestion. -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #30 from rguenther at suse dot de 2008-01-18 09:14 --- Subject: Re: [4.3 Regression] Revision 129442 breaks libstc++ API On Fri, 18 Jan 2008, bkoz at gcc dot gnu dot org wrote: --- Comment #29 from bkoz at gcc dot gnu dot org 2008-01-18 08:35 --- I asked for two votes: 1) keep removal of pre-iso includes, (ie current sources). Majority approves. 2) reinstate just iostream.h and fstream.h. Majority declines. Therefore, I am closing this as WONTFIX as per Richard's suggestion. Thanks. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-01-16 10:47 --- So, this is still a P1 regression for 4.3. Ping! (I expect Linux distributors will deal with this problem, but I also expect our customers to scream bloody murder at us for this change) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #18 from bkoz at gcc dot gnu dot org 2008-01-16 18:46 --- The ammount of breakage for this change is IMHO tolerable and will within the tolerances of other breakages that nobody is talking about reverting, and furthermore solutions for the API change are well documented. Certainly, the demonstrated breakage for the pre-iso header removal in fedora builds is about 8 packages, less than most of the individual FE changes in either 4.2 or 4.3. I believe there is a bit of a bias here, in that it's OK to make FE changes, but even well-documented and warned lib changes are not ok? What's up with that? I assert the right to make API changes, including removal of deprecated items. I believe my rationale in #6 has been missed by all. Please directly respond to this, and tell me why it's ok to remove flags and things like max/min in the C++FE, and not ok to remove deprecated headers in libstdc++. I am opposed to wholesale re-instatement of the pre-iso headers, and would like to close this as WONTFIX. From fedora build failure analysis, only two are important: iostream.h and fstream.h. If i am to be over-ruled on this issue, then please only reinstate these two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #19 from bkoz at gcc dot gnu dot org 2008-01-16 18:58 --- I'm asking for a libstdc++ maintainer vote on this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-01-16 19:06 --- I still see people use the old deprecated headers all over the place, even in newer bug reports. So it is hard to think they will be removed any time soon. I am sorry but from a QA point of view, they should be added back because it is hard to get some folks to update their code (I should know from experience with the PS3 toolchain upgrade going from 4.0.2 to 4.1.1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #21 from bkoz at gcc dot gnu dot org 2008-01-16 19:22 --- old deprecated headers all over the place Please give specifics, including what bug reports and what headers. Your experience is much different from my datapoint, which is Jakub building fedora with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. I still see this change as substantially less impactful than most of the FE changes since 3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-01-16 19:27 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34778 is one example, this example just came into today. There are many more. A lot of the windows/xbox360 based games use the deprecated headers also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #23 from rguenther at suse dot de 2008-01-16 19:40 --- Subject: Re: [4.3 Regression] Revision 129442 breaks libstc++ API On Wed, 16 Jan 2008, bkoz at gcc dot gnu dot org wrote: --- Comment #21 from bkoz at gcc dot gnu dot org 2008-01-16 19:22 --- old deprecated headers all over the place Please give specifics, including what bug reports and what headers. Your experience is much different from my datapoint, which is Jakub building fedora with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. I still see this change as substantially less impactful than most of the FE changes since 3.3. I agree with that. I am inclined to just accept whatever the libstdc++ maintainers decide on. So I would suggest to gather a vote there and close this bug as WONTFIX if the consensus is to keep the current state. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #24 from fang at csl dot cornell dot edu 2008-01-16 22:21 --- A compromise might be to provide the headers only if specifically requested, say, by -fbackward-headers (something more specific than -fpermissive). So by default, the compiler/preprocessor will now error out, but those desparate for a quick workaround can add a flag. I've seen too many projects/developers disregard the current backwards header warning (laziness? indifference?). Upgrading to an error with a workaround is yet another step on the road to deprecation. Yes, you'll still get some screams in the middle of the night (and bug reports), but at least this provides an easy way out. (IANAM, but I'd be in favor of killing the pre-ISO headers over keeping them.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #25 from mark at codesourcery dot com 2008-01-16 22:27 --- Subject: Re: [4.3 Regression] Revision 129442 breaks libstc++ API bkoz at gcc dot gnu dot org wrote: I believe there is a bit of a bias here, in that it's OK to make FE changes, but even well-documented and warned lib changes are not ok? What's up with that? I assert the right to make API changes, including removal of deprecated items. No, as I've said before, I think the C++ maintainers -- mostly me! -- were just plain wrong about some of the changes made. I think that some of the changes that were made were necessary because they were the only way to increase our ability to accept correct, conformance code. In other words, sometimes we had to choose between backwards-compatibility and correctness. In those cases, I think we were right to choose correctness. In other cases, we could have kept compatibility, but didn't. In some of those cases, I think we -- and again, mostly, be we I mean I! -- didn't try hard enough to keep backwards compatibility. We've being punished for that. (Note that there's a recent discussion about making things that are errors by default into warnings by default -- thereby making the compiler more lenient.) My -- possibly incorrect -- understanding is that in this case the problem with the old headers is not that it prevents implementation of an ISO-conformant C++ library, but just that they're a pain to keep around. My feeling is that we should be very reluctant to break backwards compatibility for maintenance reasons. Fedora (or any other GNU/Linux distribution) packages are not a good measure of the problem. They're good sample of free and/or open-source codebases compiled with G++, but they're a poor sample of all code compiled with G++. We see a lot of dusty-deck C++ code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #26 from pinskia at gcc dot gnu dot org 2008-01-16 22:34 --- I should make a mention, that I added for the GCC 4.1.1 based PS3 toolchain an option to give source compatibility for GCC 4.0.2, if anyone wants the patch, I can provide it. It was mostly C++ front-end changes too; it adds a couple of new options which could change the behavior of what is valid C++. I will most likely do the same when we upgrade to GCC 4.3.0 (if we do) so the PS3 developers don't have to change their code when updating the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #27 from bkoz at gcc dot gnu dot org 2008-01-16 23:41 --- My -- possibly incorrect -- understanding is that in this case the problem with the old headers is not that it prevents implementation of an ISO-conformant C++ library, but just that they're a pain to keep around. You are incorrect. Please do me a favor and read #6, including links, before replying to this thread. In any case, these headers have been problematic in recent times. Some don't compile (defalloc.h, perhaps others), some get in the way of other functionality (complex.h), many are completely unused, and all contribute to mental anguish on the part of maintainers struggling to keep various C++ dialects, TR1, extensions, and extension modes (debug/parallel) straight and compiling within the constraints of multiple (approved) mixings. This is far more justification than you gave for the removal of min/max although I do appreciate your commentary about backwards compat. You may be interested to know that I actually did extensive analysis of the libstdc++ api compat: see the API docs on the libstdc++ page. (Again, referenced in #6). It's been frustrating to argue this point, as there are 3 separate header changes for 4.3: removing pre-iso, new deprecations, and header streamlining. Nobody seems to pay attention as I disambiguate this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #28 from tbm at cyrius dot com 2008-01-17 06:26 --- (In reply to comment #21) Please give specifics, including what bug reports and what headers. Your experience is much different from my datapoint, which is Jakub building fedora with gcc-43. I see 8 fails 5118 packages, 7 iostream.h and 1 fstream.h. When I last compiled the Debian archive, I saw about 65 failures out of 7000 packages. Here are the headers that were missing (this adds up to more than 65 because some files include more than one header that's missing): 137 error: iostream.h: No such file or directory 99 error: fstream.h: No such file or directory 7 error: new.h: No such file or directory 5 error: stream.h: No such file or directory 4 error: vector.h: No such file or directory 3 error: iomanip.h: No such file or directory 2 error: algo.h: No such file or directory 2 error: list.h: No such file or directory 2 error: version.h: No such file or directory 1 error: alloc.h: No such file or directory 1 error: ext/hash_fun.h: No such file or directory 1 error: map.h: No such file or directory 1 error: pair.h: No such file or directory 1 error: set.h: No such file or directory 1 error: streambuf.h: No such file or directory I still see this change as substantially less impactful than most of the FE changes since 3.3. I agree with that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #15 from mark at codesourcery dot com 2007-12-17 04:34 --- Subject: Re: [4.3 Regression] Revision 129442 breaks libstc++ API rguenther at suse dot de wrote: Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000 eon still is broken, as it uses the removed iostream.h and other *.h headers - and it's impossible to fix without touching all of it) the issue isn't as pressing anymore. Though still the question remains if we should break the libstdc++ API at all. There seemed to be pretty good consensus that we shouldn't. So far, other than maintenance pain, I've not seen an argument for removing things like iostream.h. And, I think user pain should trump maintenance pain in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #16 from hjl at lucon dot org 2007-12-17 07:01 --- (In reply to comment #13) Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000 eon still is broken, as it uses the removed iostream.h and other *.h FWIW, I have 252.eon.gcc43.src.alt.tar.bz2, which works for gcc 4.x. Of course, it isn't an offical src.alt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #13 from rguenther at suse dot de 2007-12-14 10:16 --- Subject: Re: [4.3 Regression] Revision 129442 breaks libstc++ API On Fri, 14 Dec 2007, tbm at cyrius dot com wrote: I found it: http://gcc.gnu.org/ml/gcc/2007-10/msg00389.html I don't remember an explicit request for reversing of all those changes, but there was consensus that breaking the API for old application is bad. Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000 eon still is broken, as it uses the removed iostream.h and other *.h headers - and it's impossible to fix without touching all of it) the issue isn't as pressing anymore. Though still the question remains if we should break the libstdc++ API at all. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #14 from tbm at cyrius dot com 2007-12-14 14:15 --- Well, Mark asked for a good reason for removing the headers, and none was given, which would imply the next step would have been to revert their removal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #10 from bkoz at gcc dot gnu dot org 2007-12-13 17:13 --- I am unaware of a reversion request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #11 from tbm at cyrius dot com 2007-12-14 02:12 --- (In reply to comment #10) I am unaware of a reversion request. I cannot find the mail right now via the web interface and I'm travelling and my gcc mbox files are on a different machine. Maybe I'm mixing things up then. But I thought Richi sent a message complaining that SPEC (or some other major piece of software) got broken by this change and in the discussion it was agreed to revert the removal. But, like I said, I cannot find the discussion right now so maybe I dreamt it. Richi, do you remember? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #12 from tbm at cyrius dot com 2007-12-14 05:32 --- I found it: http://gcc.gnu.org/ml/gcc/2007-10/msg00389.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #9 from tbm at cyrius dot com 2007-12-13 03:03 --- I thought Mark told you two months ago to revert this patch and you didn't object. Has anything changed since then? At this point, I no longer care whether these headers are removed or not but I'd like to know for sure so I can start filing bugs. Given that gcc 4.3 will require almost all C++ code to be updated and we have several hundred bugs already, filing those ~70 bugs on packages that use old .h headers isn't that big a deal... -- tbm at cyrius dot com changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-12-11 22:56 --- The gcc-4.3 release intentionally changes the libstdc++ API. It is intended with this release that either: C++98 or C++0x will be used, and that either dialect will work with both TR1 and the various extensions listed here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#2.0 I'm interested in making this change with the least amount of trauma possible. Some cannot be avoided. The hope is that the new interfaces will be acceptable, and that the resulting library organization is coherent for the lifespan of C++0x and future library hacking. You ask: how can 4.2 and 4.3 libstdc++ APIs be differentiated? Of course, the usual hackery of GCC predefined macros applies in this situation: __GNUG__ = 4 __GNUC_MINOR__ = 3 would work. However, I think a functional test is a much better way to go. You'll find a list of autoconf macros to help you through this transition here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/backwards_compatibility.html In particular: AC_HEADER_PRE_STDCXX AC_HEADER_STDCXX_98 AC_HEADER_STDCXX_TR1 AC_HEADER_STDCXX_0X Should be sufficient to wrap client code. If these (or the other macros on this page) is insufficient, please let me know. To address your comment in #3, I will refer you to: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/api.html From this, you'll see that the majority of the backwards headers recently removed were first added for gcc-3.0.0. They have always been marked deprecated, subject to future removal. Thus, to take a longer-term view of compiler portability, their presence could never be counted on, even without the recent removal. To be completely honest, I think adding these headers in 3.0.o0 (when they were not part of gcc-2.72, gcc-2.95, egcs, etc) was a mistake. In any case, these headers have been problematic in recent times. Some don't compile (defalloc.h, perhaps others), some get in the way of other functionality (complex.h), many are completely unused, and all contribute to mental anguish on the part of maintainers struggling to keep various C++ dialects, TR1, extensions, and extension modes (debug/parallel) straight and compiling within the constraints of multiple (approved) mixings. Hope this clarifies the situation. best, benjamin best, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-12-11 22:57 --- Really the change happened too late in the release cycle which is why people are complaining about this change and it is not that advertised that it would break many people's code. In my mind, we should wait for 4.4 for this change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #8 from bkoz at gcc dot gnu dot org 2007-12-11 23:20 --- Re: #7. Sorry about the timing. I agree it is unfortunate. I do believe that the correct timing on this is to do both new C++0x interfaces and the revised backwards includes at the same time. (Certainly, this fits in with the C++98 effort history and the last backward shuffling in 2001). All in all, I consider this a distinctly minor disturbance as compared to compiler changes like -fvisibility, anon namespaces, and 3.4's two-phase lookup change. That said, suggestions for improving the docs to help with this transition would be appreciated. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #5 from tbm at cyrius dot com 2007-12-08 03:10 --- What's the status of this, Ben? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-10-28 00:53:44 |2007-10-31 21:35:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-28 00:53 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-10-28 00:53:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #3 from hjl at lucon dot org 2007-10-21 21:41 --- I believe all those header files should be restored unless we have a very good reason to break libstdc++ API. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-20 18:48 --- Actually there are 15 packages that fail out of 2500 because of this, another 6 from the ext/hash_fun.h move. I can't tell if in the other 400 packages that fail with 4.3 for various reasons there are more cases of this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
[Bug libstdc++/33831] [4.3 Regression] Revision 129442 breaks libstc++ API
--- Comment #2 from hjl at lucon dot org 2007-10-20 19:31 --- (In reply to comment #1) Actually there are 15 packages that fail out of 2500 because of this, another 6 from the ext/hash_fun.h move. I can't tell if in the other 400 packages that fail with 4.3 for various reasons there are more cases of this. I opened PR 33832 for the ext/hash_fun.h move. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
