stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brown <mark.g.br...@gmail.com>
Subject Re: [VOTE] release stdcxx 4.2.0
Date Sat, 20 Oct 2007 18:11:31 GMT
Martin Sebor wrote:
> I created what I'm hoping will be the final stdcxx 4.2.0 release
> candidate, stdcxx-4.2.0-rc-6:
> http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/
> 
> along with a tarball containing the sources:
> http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.2.0.tar.gz
> 
> The MD5 sum for the tarball is: f65ea507f7d82688d1cf241bce25dc01
> 
> Instructions on unpacking the tarball, configuring the library,
> and building it along with the set of examples and tests, are
> in the README file contained in the tarball. The file can also
> be viewed directly in Subversion:
> http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/README
> 
> The Jira "Release Notes" for 4.2.0 detailing the vast number of
> issues resolved in this release can be found here:
> http://tinyurl.com/ytzonz
> 
> stdcxx 4.2.0 has been tested on the set of platforms listed in
> the README. The test results for most of the tested platforms
> can be be viewed on the following page:
> http://people.apache.org/~sebor/stdcxx/results/
> (there are some failures, most of them due to the Rogue Wave test
> infrastructure and IT issues; please disregard those).
> 
> Please take the tarball for a spin and vote to approve the release
> and to request the approval of the Incubator PMC to publish it on
> our site.
> 
> Everyone is encouraged to vote, including non-committers.
> 
> This vote will close in the usual 72 hours.

+0, mainly because not all tests compiled.

I confirmed that the binary compatibility issue with limits has
been resolved in 12D and 11D buildtypes. Great job you guys!

Compiling the library with gcc 4.1.2 with optimization on is clean
with the exception of the two warnings below. This is a regression
from 4.1.3 which is free of these warnings. I also saw a number
of the same warnings in the examples and the test driver. I don't
know much about strict aliasing to judge if the warnings indicate
actual problems or if they are safe to ignore. Either way, I don't
necessarily see them as a reason to hold up the release. There
also are many warnings about not being able inline some functions.

Besides the warnings, the test 26.valarray.cassign.cpp gave many
compiler errors (see the attached log file) All other tests and
examples compiled okay, although many with warnings. I don't know
the stdcxx policy regarding compiler errors in tests but if the
test compilation errors are a known issue (STDCXX-512?) we might
want to disable the test in 4.2.0.

--Mark

/home/mbrown/stdcxx-4.2.0/src/ctype.cpp: In constructor 
‘std::ctype_byname<char>::ctype_byname(const char*, long unsigned int)’:
/home/mbrown/stdcxx-4.2.0/src/ctype.cpp:944: warning: dereferencing 
type-punned pointer will break strict-aliasing rules

/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h: In function ‘void 
std::return_temporary_buffer(_TypeT*) [with _TypeT = 
std::ios_base::_C_usr_data::_C_event_cb]’:
/home/mbrown/stdcxx-4.2.0/src/iostore.cpp:151:   instantiated from here
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h:164: warning: 
dereferencing type-punned pointer will break strict-aliasing rules
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h: In function 
‘std::pair<_TypeT*, _Distance> std::get_temporary_buffer(_Distance, 
_TypeT*) [with _TypeT = std::ios_base::_C_usr_data::_C_event_cb, 
_Distance = long int]’:
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h:153:   instantiated from 
‘std::pair<_TypeT*, long int> std::get_temporary_buffer(long int) [with 
_TypeT = std::ios_base::_C_usr_data::_C_event_cb]’
/home/mbrown/stdcxx-4.2.0/src/iostore.cpp:120:   instantiated from here
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h:138: warning: 
dereferencing type-punned pointer will break strict-aliasing rules
g

Mime
View raw message