Ulrich Weigand wrote:
> Comparing the cp/ChangeLog files from 4.0.2 and the 4_0 branch, it looks
> like the fix is in the release according to the current ChangeLog, but
> in fact it wasn't:
Indeed, cvs log confirms that the revision was made to cp/init.c on
September 22.
It appears that the release automation failed, and that, in fact, the
allegedly final GCC 4.0.2 bits are in fact the early version of GCC
4.0.2 that I never uploaded because of the last-minute changes for
Solaris and such.
I'm incredibly depressed.
I suspect that the reason for this is that gcc_release does:
inform "Tagging sources as ${TAG}"
# The -F option to CVS is intentionally not used below. If you
# need to retry a release, you will have to manually remove any
# existing tag.
${CVS} rtag -r ${CVSBRANCH} ${TAG} gcc || \
error "Could not tag sources"
EXPORTTAG="-r${TAG}"
and then:
${CVS} export -d "`basename ${SOURCE_DIRECTORY}`" \
"${EXPORTTAG}" gcc || \
I didn't realize that I had to manually remove the old tag.
Furthermore, I guess that "cvs rtag" did not fail (so the error case did
not occur), even though it did not move the tag. So, even though all
the right bits were checked in, they didn't end up in the exported
source directory.
I'm not sure what to do.
The bits that appear to be missing are the Solaris change to libstdc++:
2005-09-25 Benjamin Kosnik <[EMAIL PROTECTED]>
Eric Botcazou <[EMAIL PROTECTED]>
* include/ext/mt_allocator.h
(__per_type_pool<...true>::_S_initialize_once): Always call
_M_initialize_once.
(__common_pool<...true>::_S_initialize_once): Same.
and my change to C++:
2005-09-21 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/23993
* init.c (integral_constant_value): Use
DECL_INTEGRAL_CONSTANT_VAR_P.
and Andreas' change:
2005-09-21 Andreas Schwab <[EMAIL PROTECTED]>
PR rtl-optimization/23043
* postreload-gcse.c (eliminate_partially_redundant_load): Fix typo
when allocating a struct unoccr.
The key question is whether to do an immediate 4.0.3 to catch up to what
we intended. (That's not entirely trivial, in that things have now been
checked in on the 4.0 branch, so we would have to temporarily back out
some patches, or apply tags very carefully.) Or, we could do a 4.0.3
based on current bits.
My inclination is to do nothing (other than correct the target
milestones on these bugs in bugzilla) and move on. The Solaris problem
is bad, and I beat up on Benjamin to get it fixed, but I'm not sure it's
a crisis meriting another release cycle. The C++ change fixed a
regression relative to 3.4.x, but not 4.0.x. Andreas' change is only
known to affect m68k.
I'd appreciate feedback. (I don't promise to be bound by the majority
view, though.)
I'd also appreciate suggestions for making the release script more
robust in this situation; clearly, depending on cvs rtag to fail is
clearly not sufficiently reliable.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
