Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <471A7D69.8060003@roguewave.com>
Date: Sat, 20 Oct 2007 16:12:57 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: [VOTE] release stdcxx 4.2.0
References: <47180BDA.40002@roguewave.com> <471A44D3.5020607@gmail.com>
In-Reply-To: <471A44D3.5020607@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Mark Brown wrote:
> 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!

Thanks. It wasn't easy.

> 
> 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.

This is actually a known issue although we didn't realize that
it was a regression -- see:
   http://issues.apache.org/jira/browse/STDCXX-350

> 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.

I don't know much about the consequences of breaking the gcc
strict aliasing rules either, but from the little I've read
online it sounds like they could be pretty dire because the
compiler apparently doesn't do a full data flow analysis and
might lose track of the fact that the same piece of data is
being accessed through two different pointers (or something
like that). Since it's a regression , the fix is easy and
non-invasive, and since we've already made a change to 4.2.0
that will require us to create another candidate we might as
well err on the side of caution and fix it. I've tested and
committed the following change:
   http://svn.apache.org/viewvc?rev=586811&view=rev

> 
> 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.

Agreed. I disabled the problematic specialization with this
change:
   http://svn.apache.org/viewvc?rev=586808&view=rev.

Martin

> 
> --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