Re: [boost] Boost regression notification (2005-10-06 [RC_1_33_0])
(re-sending as the server that hosts this mail account rebooted as I sent the mail and it hasn't shown up in the archives yet ...) Martin Wille wrote:
Arkadiy Vertleyb wrote:
"Douglas Gregor" <doug.gregor@gmail.com> wrote
Is GCC's debug mode a release-critical platform ?
No.
How can this be? How useful is a feature that can be used in the release mode oinly? I think its usefullness is pretty close to zero...
I agree with your questioning, Arkadiy.
I completely fail to understand the question. The debug mode cannot be used in "release mode" because it makes the stdlib non-conforming. It's useful for tracking down problems in your code, and as such is immensely useful, but it's not meant for production code in "release mode" What do you mean "a feature that can be used in the release mode only" ?
People will want to use the debug mode. It's probably the best thing added to recent libstdc++ distributions. Severals bugs in Boost code were discovered using _GLIBCXX_DEBUG. I'd consider it a big loss not to be able to use it anymore.
I'm not saying "you can't use it anymore" - just that the Boost release shouldn't be held up by debug-mode failures that don't affect any major platforms in their normal configuration. If you're willing, try running the tests with libstdc++ concept-checks enabled as well (#define _GLIBCXX_CONCEPT_CHECKS) and then let me know if you think the release should be held up for those bugs too. Personally I think they're more important than the debug-mode failures, since it's possible to configure GCC so that concept-checks are enabled by default, making parts of Boost unusable. But debug mode is always off by default. jon
Jonathan Wakely wrote:
I'm not saying "you can't use it anymore" - just that the Boost release shouldn't be held up by debug-mode failures that don't affect any major platforms in their normal configuration.
I'm claiming debug mode is a normal configuration. People want to be able to get debugging aid by turning _GLIBCXX_DEBUG on. If Boost isn't as usable in the debug mode as it is in release mode then this is a significant impact on usability.
If you're willing, try running the tests with libstdc++ concept-checks enabled as well (#define _GLIBCXX_CONCEPT_CHECKS) and then let me know if you think the release should be held up for those bugs too.
Hmm, I didn't know of that. Sounds interesting. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
I'm not saying "you can't use it anymore" - just that the Boost release shouldn't be held up by debug-mode failures that don't affect any major platforms in their normal configuration.
I'm claiming debug mode is a normal configuration. People want to be able to get debugging aid by turning _GLIBCXX_DEBUG on. If Boost isn't as usable in the debug mode as it is in release mode then this is a significant impact on usability.
I agree, the point is this mode does catch bugs, and we should test with it. However there are only so many new requirements we can introduce for a release and still get it out. This should be a requirement for 1.34 not 1.33.1 IMO.
If you're willing, try running the tests with libstdc++ concept-checks enabled as well (#define _GLIBCXX_CONCEPT_CHECKS) and then let me know if you think the release should be held up for those bugs too.
Hmm, I didn't know of that. Sounds interesting.
Again sounds like a useful test to add for 1.34. John.
John Maddock wrote:
I'm not saying "you can't use it anymore" - just that the Boost release shouldn't be held up by debug-mode failures that don't affect any major platforms in their normal configuration.
I'm claiming debug mode is a normal configuration. People want to be able to get debugging aid by turning _GLIBCXX_DEBUG on. If Boost isn't as usable in the debug mode as it is in release mode then this is a significant impact on usability.
I agree, the point is this mode does catch bugs, and we should test with it.
However there are only so many new requirements we can introduce for a release and still get it out. This should be a requirement for 1.34 not 1.33.1 IMO.
I used _GLIBCXX_DEBUG for 1.32, already, IIRC (it was already used for testing against prerelease versions of gcc 3.4). _GLIBCXX_DEBUG was definitely used for 1.33.0. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
I used _GLIBCXX_DEBUG for 1.32, already, IIRC (it was already used for testing against prerelease versions of gcc 3.4). _GLIBCXX_DEBUG was definitely used for 1.33.0.
My misunderstanding then. In that case it should be a release requirement, with the usual proviso that if you can show it's a bug in the compiler or std lib then we may make an exception. John.
On Oct 10, 2005, at 5:49 AM, Martin Wille wrote:
John Maddock wrote:
However there are only so many new requirements we can introduce for a release and still get it out. This should be a requirement for 1.34 not 1.33.1 IMO.
I used _GLIBCXX_DEBUG for 1.32, already, IIRC (it was already used for testing against prerelease versions of gcc 3.4). _GLIBCXX_DEBUG was definitely used for 1.33.0.
And, as usual, I should read all my mail before answering any of it :) Since we're already doing it, let's keep on testing wit h_GLIBCXX_DEBUG. Doug
On Oct 10, 2005, at 4:53 AM, John Maddock wrote:
I'm not saying "you can't use it anymore" - just that the Boost release shouldn't be held up by debug-mode failures that don't affect any major platforms in their normal configuration.
I'm claiming debug mode is a normal configuration. People want to be able to get debugging aid by turning _GLIBCXX_DEBUG on. If Boost isn't as usable in the debug mode as it is in release mode then this is a significant impact on usability.
I agree, the point is this mode does catch bugs, and we should test with it.
Yes.
However there are only so many new requirements we can introduce for a release and still get it out. This should be a requirement for 1.34 not 1.33.1 IMO.
Right. Doug
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
The debug mode cannot be used in "release mode" because it makes the stdlib non-conforming.
I'd like to see some pretty clear proof that libstdc++ is nonconforming in debug mode. As far as I'm concerned, the onus is on the developer whose code is triggering the assertions. I'd be overjoyed if libstdc++ were proven wrong, of course. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Jonathan Wakely writes:
The debug mode cannot be used in "release mode" because it makes the stdlib non-conforming.
I'd like to see some pretty clear proof that libstdc++ is nonconforming in debug mode. As far as I'm concerned, the onus is on the developer whose code is triggering the assertions. I'd be overjoyed if libstdc++ were proven wrong, of course.
OK, we seem to be talking at cross-purposes here - and you've taken my quote out of context (but I'm still right ;-) Arkadiy hasn't clarified what he meant by release mode, but I assumed he meant something like "the compiler settings you'd use when building a release that you'll ship to customers." Libstdc++'s Debug Mode is not standard-conforming. Read the docs if you want clear proof: performance guarantees made by the normal library may not hold in the debug mode library. For instance, erasing an element in a std::list is a constant-time operation in [the] normal library, but in debug mode it is linear in the number of iterators that reference that particular list. Or ask Doug Gregor - he wrote that, I believe. The iterators and containers do not provide the complexity guarantees of the standard. So you'd be foolish to use it for "release builds" (unless we're talking some weird definition of release that isn't concerned with exponential increases in runtime.) That doesn't mean the debug mode is wrong if it causes some Boost code to fail. It doesn't mean you shouldn't try to make Boost correct w.r.t the debug mode. All I tried to suggest was the the debug mode failures might not be top priority. I'm happy to be wrong, if you can make Boost 1.33.1 work perfectly with the debug mode, then that's great. As for conformance / non-conformance, that arose out of a question from Arkadiy that I don't understand and he hasn't explained. The fact is it's non-conforming and should not be used for "release builds" - but I thought naming it "debug mode" made that obvious. jon
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
Libstdc++'s Debug Mode is not standard-conforming. Read the docs if you want clear proof:
performance guarantees made by the normal library may not hold in the debug mode library. For instance, erasing an element in a std::list is a constant-time operation in [the] normal library, but in debug mode it is linear in the number of iterators that reference that particular list.
Well, I guess that's arguable, since it's still constant time in the length of the list, which is (I think) all the standard guarantees ;) Anyway, it's conforming functionally, just not efficiency-wise.
The iterators and containers do not provide the complexity guarantees of the standard. So you'd be foolish to use it for "release builds" (unless we're talking some weird definition of release that isn't concerned with exponential increases in runtime.)
Right.
That doesn't mean the debug mode is wrong if it causes some Boost code to fail.
Right.
It doesn't mean you shouldn't try to make Boost correct w.r.t the debug mode.
Right.
All I tried to suggest was the the debug mode failures might not be top priority.
That's where we part company. If your code is causing a failure in debug mode, either the debug mode (or the compiler) has a bug, or your code is invoking undefined behavior and will probably crash in the field. That's a serious bug that needs to be fixed -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
David Abrahams -
Doug Gregor -
John Maddock -
Jonathan Wakely -
Martin Wille