1.31.0 closed for changes without permission
Please make no more changes to the RC_1_31_0 branch without the release manager's permission. The one exception is removal of is_abstract code. We need to be totally stable so that the regression tests can cycle one last time. --Beman PS: For the next release, we need to define written "release discipline". What kind of changes are allowed at various points, such as after branch, after release candidates start, etc.
Beman Dawes wrote:
PS: For the next release, we need to define written "release discipline". What kind of changes are allowed at various points, such as after branch, after release candidates start, etc.
My $0.02 worth: After branch, only planned (announced, discussed, etc) new features, bug fixes and documentation additions. One week before RC1, only bug fixes and documentation additions. After RC1 only bug fixes to bugs exposed by existing regression tests. Draconian? Perhaps. But we need to get the release process into a manageable form, and having changes checked in with wild abandon during the release process is not going to lead to a more manageable process. -cd
The RC_1_31_0 branch is currently broken on most (all?) platforms: boost/boost/type_traits.hpp:27:45: boost/type_traits/is_abstract.hpp: No such file or directory Ralf __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
The current RC_1_31_0 branch, after locally removing the is_abstract include from boost/type_traits.hpp, does not work with the most current gcc-3_4_branch. The combination of RC_1_31_0 and gcc 3.4 was working when I checked the last time three weeks ago. I will submit a gcc bug report later today. However, it is not a given that the gcc people will fix the ICE before their release. Therefore I'd like to find out if a simple rearrangement of the boost code is sufficient to work around the gcc ICE. This approach has worked many times in the past. I'll try to work on this later today. Ralf g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/worm/scratch1/rwgk/rc1310/boost -I/usr/include/python2.2 -c -o boost/libs/python/src/dict.os /net/worm/scratch1/rwgk/rc1310/boost/libs/python/src/dict.cpp In file included from /net/worm/scratch1/rwgk/rc1310/boost/boost/mpl/advance.hpp:20, from /net/worm/scratch1/rwgk/rc1310/boost/boost/mpl/aux_/at_impl.hpp:21, from /net/worm/scratch1/rwgk/rc1310/boost/boost/mpl/at.hpp:22, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/detail/signature.hpp:20, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/detail/caller.hpp:16, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/object/function_handle.hpp:9, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/converter/arg_to_python.hpp:20, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/call.hpp:16, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/object_core.hpp:13, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/object.hpp:10, from /net/worm/scratch1/rwgk/rc1310/boost/boost/python/dict.hpp:11, from /net/worm/scratch1/rwgk/rc1310/boost/libs/python/src/dict.cpp:1: /net/worm/scratch1/rwgk/rc1310/boost/boost/mpl/negate.hpp:38: internal compiler error: in uses_template_parms, at cp/pt.c:4748 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
--- "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> wrote:
I will submit a gcc bug report later today. However, it is not a given that the gcc people will fix the ICE before their release. Therefore I'd like to find out if a simple rearrangement of the boost code is sufficient to work around the gcc ICE. This approach has worked many times in the past. I'll try to work on this later today.
The trivial patches below do the trick. I think it would be good to apply them to the RC_1_31_0 branch. It would be a pitty if Boost 1.31.0 did not work with the next gcc release. I'll go ahead and use the boost CVS HEAD to submit a gcc bug report. Ralf Index: minus.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/minus.hpp,v retrieving revision 1.1 diff -u -r1.1 minus.hpp --- minus.hpp 25 Feb 2003 23:10:44 -0000 1.1 +++ minus.hpp 1 Feb 2004 23:13:44 -0000 @@ -34,7 +34,8 @@ struct minus_c { BOOST_STATIC_CONSTANT(T, value = (N1 - N2 - N3 - N4 - N5)); -#if !defined(__BORLANDC__) +#if !defined(__BORLANDC__) \ + && !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 4 && __GNUC_PATCHLEVEL__ == 0) typedef integral_c<T,value> type; #else typedef integral_c<T,(N1 - N2 - N3 - N4 - N5)> type; Index: negate.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/negate.hpp,v retrieving revision 1.1 diff -u -r1.1 negate.hpp --- negate.hpp 25 Feb 2003 23:10:45 -0000 1.1 +++ negate.hpp 1 Feb 2004 23:13:44 -0000 @@ -34,7 +34,8 @@ { typedef BOOST_MPL_AUX_TYPEOF(T,T::value) value_type; BOOST_STATIC_CONSTANT(value_type, value = (-T::value)); -#if !defined(__BORLANDC__) +#if !defined(__BORLANDC__) \ + && !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 4 && __GNUC_PATCHLEVEL__ == 0) typedef integral_c<value_type, value> type; #else typedef integral_c<value_type, (-T::value)> type; Index: plus.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/plus.hpp,v retrieving revision 1.2 diff -u -r1.2 plus.hpp --- plus.hpp 20 May 2003 18:55:44 -0000 1.2 +++ plus.hpp 1 Feb 2004 23:13:44 -0000 @@ -34,7 +34,8 @@ struct plus_c { BOOST_STATIC_CONSTANT(T, value = (N1 + N2 + N3 + N4 + N5)); -#if !defined(__BORLANDC__) +#if !defined(__BORLANDC__) \ + && !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ == 4 && __GNUC_PATCHLEVEL__ == 0) typedef integral_c<T,value> type; #else typedef integral_c<T,(N1 + N2 + N3 + N4 + N5)> type; __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
--- "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> wrote:
I'll go ahead and use the boost CVS HEAD to submit a gcc bug report.
Here it is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13968 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Ralf W. Grosse-Kunstleve wrote:
I will submit a gcc bug report later today. However, it is not a given that the gcc people will fix the ICE before their release.
They are regressions caused by recent work on speeding up the compiler, and they *will* be fixed before the release. Please, make sure to specify that Boost is broken because of these bugs. -- Giovanni Bajo
On Mon, 2 Feb 2004, Giovanni Bajo wrote:
Ralf W. Grosse-Kunstleve wrote:
I will submit a gcc bug report later today. However, it is not a given that the gcc people will fix the ICE before their release.
They are regressions caused by recent work on speeding up the compiler, and they *will* be fixed before the release. Please, make sure to specify that Boost is broken because of these bugs.
I believe we should not commit any GCC 3.4-specific workarounds until after GCC 3.4 is finalized. It hides compiler bugs that we still have a chance to get fixed. Doug
--- Douglas Paul Gregor <gregod@cs.rpi.edu> wrote:
On Mon, 2 Feb 2004, Giovanni Bajo wrote:
Ralf W. Grosse-Kunstleve wrote:
I will submit a gcc bug report later today. However, it is not a given that the gcc people will fix the ICE before their release.
They are regressions caused by recent work on speeding up the compiler, and they *will* be fixed before the release. Please, make sure to specify that Boost is broken because of these bugs.
I believe we should not commit any GCC 3.4-specific workarounds until after GCC 3.4 is finalized.
That's too late for the Boost 1.31.0 release. I never suggested committing the changes to the HEAD, just to the release branch. I don't see what harm they could do there. On the other hand I am very anxious to see the next Boost release work in as many environments as possible. Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
On Sun, 1 Feb 2004, Ralf W. Grosse-Kunstleve wrote:
--- Douglas Paul Gregor <gregod@cs.rpi.edu> wrote:
I believe we should not commit any GCC 3.4-specific workarounds until after GCC 3.4 is finalized.
That's too late for the Boost 1.31.0 release. I never suggested committing the changes to the HEAD, just to the release branch. I don't see what harm they could do there. On the other hand I am very anxious to see the next Boost release work in as many environments as possible. Ralf
This is the type of thing that delays Boost releases. It looks like an innocuous change, but who knows? Maybe it triggers an annoying preprocessor bug in one compiler somewhere, and it takes us 2 days to find out, back out the changes, and get another clean run of the regression tests. Beman wants only critical bug fixes on the release branch, and I don't see how we can justify a workaround for an unreleased compiler as a critical bug fix. Doug
At 09:06 PM 2/1/2004, Douglas Paul Gregor wrote:
--- Douglas Paul Gregor <gregod@cs.rpi.edu> wrote:
I believe we should not commit any GCC 3.4-specific workarounds until after GCC 3.4 is finalized.
That's too late for the Boost 1.31.0 release. I never suggested committing
changes to the HEAD, just to the release branch. I don't see what harm
On Sun, 1 Feb 2004, Ralf W. Grosse-Kunstleve wrote: the they
could do there. On the other hand I am very anxious to see the next Boost release work in as many environments as possible. Ralf
This is the type of thing that delays Boost releases. It looks like an innocuous change, but who knows? Maybe it triggers an annoying preprocessor bug in one compiler somewhere, and it takes us 2 days to find out, back out the changes, and get another clean run of the regression tests. Beman wants only critical bug fixes on the release branch, and I don't see how we can justify a workaround for an unreleased compiler as a critical bug fix.
Agree 100%. We just saw a case where an apparently innocuous change caused a compiler ICE. If I understand Giovanni Bajo's posting correctly, the gcc bug is scheduled to be fixed, and the very fact that Boost's latest release triggers the bug increases the probability of it being fixed. Besides a general feeling that it is high time to get this release out the door, it is less that two weeks until the deadline for papers for the next C++ committee meeting. Several of us badly need to shift attention to getting material ready for that. After a phone conversation earlier this evening, I gave Dave Abrahams permission to commit a fix for the iterator adaptor issue Robert Ramey reported. Jeff Garland has finished some docs changes he requested permission to make this morning. A hopefully final set of my Win32 regression tests has run and been uploaded. Other tests will cycle overnight, and if they look good in the morning I'll put final release candidates together then. --Beman
Beman Dawes wrote:
If I understand Giovanni Bajo's posting correctly, the gcc bug is scheduled to be fixed, and the very fact that Boost's latest release triggers the bug increases the probability of it being fixed.
Exactly. -- Giovanni Bajo
--- Giovanni Bajo <giovannibajo@libero.it> wrote:
Beman Dawes wrote:
If I understand Giovanni Bajo's posting correctly, the gcc bug is scheduled to be fixed, and the very fact that Boost's latest release triggers the bug increases the probability of it being fixed.
Exactly.
I take your word, guys! :) Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/
Douglas Paul Gregor wrote:
I will submit a gcc bug report later today. However, it is not a given that the gcc people will fix the ICE before their release.
They are regressions caused by recent work on speeding up the compiler, and they *will* be fixed before the release. Please, make sure to specify that Boost is broken because of these bugs.
I believe we should not commit any GCC 3.4-specific workarounds until after GCC 3.4 is finalized. It hides compiler bugs that we still have a chance to get fixed.
Yes, in fact I completely agree. -- Giovanni Bajo
Beman Dawes <bdawes@acm.org> wrote in message news:4.3.2.7.2.20040201093334.02fc0e00@mailhost.esva.net...
Please make no more changes to the RC_1_31_0 branch without the release manager's permission.
There is one change to "optional_test.cpp" (that is, the test, not the library) that affects ONLY bcc5.6.4 which currently shows as broken. This change is to fix the test which is wrong w.r.t the current optional code for this compiler. This change will not affect any other compiler (because it consist of removing the bcc5.6.4 specific code) and will fix the test for that compiler. If it is OK to apply this change to 1.31.0 I'll proceed; otherwise, I'll left the fix only in the main trunk. Fernando Cacciola SciSoft
At 10:41 AM 2/2/2004, Fernando Cacciola wrote:
Beman Dawes <bdawes@acm.org> wrote in message news:4.3.2.7.2.20040201093334.02fc0e00@mailhost.esva.net...
Please make no more changes to the RC_1_31_0 branch without the release manager's permission.
There is one change to "optional_test.cpp" (that is, the test, not the library) that affects ONLY bcc5.6.4 which currently shows as broken. This change is to fix the test which is wrong w.r.t the current optional code for this compiler.
This change will not affect any other compiler (because it consist of removing the bcc5.6.4 specific code) and will fix the test for that compiler.
If it is OK to apply this change to 1.31.0 I'll proceed; otherwise, I'll left the fix only in the main trunk.
OK, you can make it to 1.31.0, since we have to complete one more regression cycle anyhow. But only if (1) you can do it right away and (2) you watch the Win32 tests which I will update as soon as I see your change applied and (3) you back it out instantly if it causes trouble. --Beman
"Beman Dawes" <bdawes@acm.org> escribió en el mensaje news:4.3.2.7.2.20040202115251.0379d168@mailhost.esva.net...
At 10:41 AM 2/2/2004, Fernando Cacciola wrote:
Beman Dawes <bdawes@acm.org> wrote in message news:4.3.2.7.2.20040201093334.02fc0e00@mailhost.esva.net...
Please make no more changes to the RC_1_31_0 branch without the
release
manager's permission.
[snip change explanation] If it is OK to apply this change to 1.31.0 I'll proceed; otherwise, I'll left the fix only in the main trunk.
OK, you can make it to 1.31.0, since we have to complete one more regression cycle anyhow. But only if (1) you can do it right away and (2) you watch the Win32 tests which I will update as soon as I see your change applied and (3) you back it out instantly if it causes trouble.
Hi, I had a problem and needed to run off the computer, and I couldn't get back until now; sorry. Is it still possible to make it? Fernando Cacciola SciSoft
At 05:01 PM 2/2/2004, Fernando Cacciola wrote:
"Beman Dawes" <bdawes@acm.org> escribió en el mensaje news:4.3.2.7.2.20040202115251.0379d168@mailhost.esva.net...
At 10:41 AM 2/2/2004, Fernando Cacciola wrote:
Beman Dawes <bdawes@acm.org> wrote in message news:4.3.2.7.2.20040201093334.02fc0e00@mailhost.esva.net...
Please make no more changes to the RC_1_31_0 branch without the
release
manager's permission.
[snip change explanation] If it is OK to apply this change to 1.31.0 I'll proceed; otherwise, I'll left the fix only in the main trunk.
OK, you can make it to 1.31.0, since we have to complete one more regression cycle anyhow. But only if (1) you can do it right away and
(2)
you watch the Win32 tests which I will update as soon as I see your change applied and (3) you back it out instantly if it causes trouble.
Hi,
I had a problem and needed to run off the computer, and I couldn't get back until now; sorry. Is it still possible to make it?
If you do it instantly (so Metacomm's tests get the updated files when they run at midnight. I think they are US Central time). --Beman
Beman Dawes wrote:
At 05:01 PM 2/2/2004, Fernando Cacciola wrote:
"Beman Dawes" <bdawes@acm.org> escribió en el mensaje news:4.3.2.7.2.20040202115251.0379d168@mailhost.esva.net...
At 10:41 AM 2/2/2004, Fernando Cacciola wrote:
Beman Dawes <bdawes@acm.org> wrote in message news:4.3.2.7.2.20040201093334.02fc0e00@mailhost.esva.net...
Please make no more changes to the RC_1_31_0 branch without
the >release
manager's permission.
[snip change explanation] If it is OK to apply this change to 1.31.0 I'll proceed; otherwise, >I'll left the fix only in the main trunk.
OK, you can make it to 1.31.0, since we have to complete one more regression cycle anyhow. But only if (1) you can do it right away and (2) you watch the Win32 tests which I will update as soon as I see your >change applied and (3) you back it out instantly if it causes trouble.
Hi,
I had a problem and needed to run off the computer, and I couldn't get back until now; sorry. Is it still possible to make it?
If you do it instantly (so Metacomm's tests get the updated files when they run at midnight. I think they are US Central time).
OK, I'll do it right now.... Fernando Cacciola SciSoft
Beman Dawes wrote:
At 05:01 PM 2/2/2004, Fernando Cacciola wrote:
"Beman Dawes" <bdawes@acm.org> escribió en el mensaje news:4.3.2.7.2.20040202115251.0379d168@mailhost.esva.net...
At 10:41 AM 2/2/2004, Fernando Cacciola wrote:
Beman Dawes <bdawes@acm.org> wrote in message news:4.3.2.7.2.20040201093334.02fc0e00@mailhost.esva.net...
Please make no more changes to the RC_1_31_0 branch without
the >release
manager's permission.
[snip change explanation] If it is OK to apply this change to 1.31.0 I'll proceed; otherwise, >I'll left the fix only in the main trunk.
OK, you can make it to 1.31.0, since we have to complete one more regression cycle anyhow. But only if (1) you can do it right away and (2) you watch the Win32 tests which I will update as soon as I see your >change applied and (3) you back it out instantly if it causes trouble.
Hi,
I had a problem and needed to run off the computer, and I couldn't get back until now; sorry. Is it still possible to make it?
If you do it instantly (so Metacomm's tests get the updated files when they run at midnight. I think they are US Central time).
Done, I'll watch the regressions and I'll undoit inmediately if there's any problem. Fernando Cacciola SciSoft
At 10:22 PM 2/2/2004, Fernando Cacciola wrote:
If you do it instantly (so Metacomm's tests get the updated files when they run at midnight. I think they are US Central time).
Done, I'll watch the regressions and I'll undoit inmediately if there's any problem.
Looks good, at least on the tests I run here. --Beman
participants (2)
-
Beman Dawes -
Carl Daniel -
Douglas Paul Gregor -
Fernando Cacciola -
Giovanni Bajo -
John Maddock -
Ralf W. Grosse-Kunstleve